Request based caching of data store data

ABSTRACT

A request, such as those embedded in URLs and XML documents, is assigned to a thread of execution in a server that is in communication with a data store. The thread of execution includes a thread local storage with a pointer to a cache object. The cache object maintains copies of data store entries frequently accessed by the assigned request. The cache object is accessed in response to data store access commands arising from the request. When a data store access command specifies a data store entry not found in the cache object, the server creates and loads a corresponding cache object entry. The cache object is not updated when other requests alter data store entries, and memory access commands arising from other requests cannot cause the cache object to be accessed. When the request causes the server to write data to the data store, the cache object also maintains a copy of the written data. The server retrieves the written data from the cache object in response to subsequent data store access queries arising from the request. The cache object is destroyed once the server completes a response to the request.

[0001] This application claims the benefit of U.S. ProvisionalApplication No. 60/258,087, “Integrated Identity and Access ManagementSystems With Group and Organization Managers,” filed on Dec. 22, 2000;and U.S. Provisional Application No. 60/285,524, “Integrated Identityand Access Management System,” filed on Apr. 20, 2001; both of which areincorporated herein by reference.

COPYRIGHT NOTICE

[0002] A portion of the disclosure of this patent document containsmaterial, which is subject to copyright protection. The copyright ownerhas no objection to the reproduction by anyone of the patent document orthe patent disclosure as it appears in the United States Patent andTrademark Office patent file or records, but otherwise reserves allcopyright rights whatsoever.

BACKGROUND OF THE INVENTION

[0003] 1. Field of the Invention

[0004] The present invention is directed to technology for providingrequest based caching on a server.

[0005] 2. Description of the Related Art

[0006] Identity Systems have become more popular with the growth of theInternet and the use of networks and other information technologies. Ingeneral, an Identity System provides for the creation, removal, editingand other management of identity information stored in various types ofdata stores. The identity information pertains to users, groups,organizations and/or things. For each entry in the data store, a set ofattributes is stored. For example, the attributes stored for a user mayinclude a name, address, employee number, telephone number, emailaddress, user ID and password. The Identity System can also manageaccess privileges that govern the subject matter an entity can view,create, modify or use in the Identity System.

[0007] Identity System users direct the operation of the Identity Systemby submitting requests that call for an Identity System response, such asearching and viewing a user's profile. Requests frequently require theIdentity System to repeatedly access the same entries in the IdentitySystem's data store. For example, a request may cause the IdentitySystem to load data into a data store entry and later retrieve the newlyloaded data multiple times for performing different functions. This canoccur when a client provides identification information that is storedin a data store entry. The request may retrieve this information onmultiple occasions for forwarding to servers or applications accessed bythe client request.

[0008] Accessing the same data store entries multiple times for a singlerequest slows request processing and wastes data store bandwidth. It isdesirable to reduce the number of times a data store entry is accessedin response to a single request.

SUMMARY OF THE INVENTION

[0009] The present invention, roughly described, reduces repeatedaccesses to the same data store entry by providing request based cachingof data store entries.

[0010] Each client request is assigned to a thread of execution in anIdentity Server within an Identity System. A cache object is associatedwith the thread of execution for caching data store entry accessesarising from the request. In one implementation, the thread of executioncontains a thread local storage with a pointer to the cache object.Employing the cache object to maintain frequently accessed data storeentries reduces the number of data store accesses required to servicethe request—speeding request processing time and freeing data storebandwidth.

[0011] In one embodiment of the present invention, an Identity Serverreceiving a request interprets a command in the request to call for anaccess to a data store entry. In response to the command, the IdentityServer accesses a first entry in the cache object that corresponds tothe data store entry called for in the command. If the cache object doesnot include an entry corresponding to the data store entry, the IdentityServer creates and loads a corresponding entry in the cache object.

[0012] If a data store access command calls for a value to be written tothe data store entry, the Identity Server writes the value to both thecache object and the data store. This ensures that the data store is upto date for other threads of execution. When the Identity Serverencounters a subsequent query command arising from the request for thesame data store entry, the Identity Server only needs to retrieve thedata written to the cache object. This allows the Identity Server torespond to the request with the most recent data without requiring adata store access.

[0013] The cache object is only accessible to the Identity Serverresponding to the request, and the cache object is not updated whenother requests alter data store entries. In one instance, the cacheobject is not accessed in response to any other requests, and the cacheobject is destroyed once the Identity Server completes the response tothe request.

[0014] In further embodiments of the present invention, request basedcaching is employed in processing environments other than an IdentitySystem. Request based caching can have broad applicability to enhancethe performance of many different server based systems.

[0015] The present invention can be accomplished using hardware,software, or a combination of both hardware and software. The softwareused for the present invention is stored on one or more processorreadable storage media including hard disk drives, CD-ROMs, DVDs,optical disks, floppy disks, tape drives, RAM, ROM or other suitablestorage devices. In alternative embodiments, some or all of the softwarecan be replaced by dedicated hardware including custom integratedcircuits, gate arrays, FPGAs, PLDs, and special purpose computers.

[0016] These and other objects and advantages of the present inventionwill appear more clearly from the following description in which thepreferred embodiment of the invention has been set forth in conjunctionwith the drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

[0017]FIG. 1 is a block diagram depicting the components of oneembodiment of the present invention.

[0018]FIG. 2 is a block diagram depicting exemplar components of acomputing system that can be used to implement the present invention.

[0019]FIG. 3 is a block diagram depicting an embodiment of the presentinvention that supports multiple data stores.

[0020]FIG. 4 is a flow chart describing one embodiment of a process forsupporting multiple data stores.

[0021]FIG. 5 is an example of a directory tree structure.

[0022]FIG. 6 is a flow chart describing one embodiment of a process foraccessing the Identity System.

[0023]FIG. 7 is a block diagram of a cookie.

[0024]FIG. 8 is a block diagram depicting the User Manager.

[0025]FIG. 9 is a block diagram depicting the Group Manager.

[0026]FIG. 10 is a block diagram depicting the Organization Manager.

[0027]FIG. 11 is a flow chart describing one embodiment of a process forconfiguring rights to access attributes.

[0028]FIG. 12 is a flow chart describing one embodiment of a process forallowing an entity to view attributes

[0029]FIG. 13 is a flow chart describing one embodiment of a process fordelegating rights.

[0030]FIG. 14 is a flow chart describing one embodiment of a process forenabling another to be a proxy.

[0031]FIG. 15 is a flow chart describing one embodiment of a process forbecoming a proxy for another.

[0032]FIG. 16 is a flow chart describing an overview of a process forcreating and using workflows.

[0033]FIG. 17 is a flow chart describing one embodiment of a process forcreating a template.

[0034]FIG. 18 is a flow chart describing one embodiment of a process forcreating a workflow.

[0035]FIG. 19 is a flow chart describing one embodiment of a process fordefining steps for a workflow.

[0036]FIG. 20 is a flow chart describing one embodiment of a process forusing a workflow.

[0037]FIG. 21 is a flow chart describing one embodiment of a process forusing a subflow.

[0038]FIG. 22 is a flow chart describing one embodiment of a process forcreating a cross application workflow.

[0039]FIG. 23 is a flow chart describing one embodiment of a processperformed to implement a cross application workflow.

[0040]FIG. 24 is a flow chart describing one embodiment of a processperformed by a workflow client program to implement a cross applicationworkflow.

[0041]FIG. 25 is a flow chart describing one embodiment of a process forviewing all groups of an entity.

[0042]FIG. 26 is a flow chart describing a second embodiment of aprocess for viewing all groups of an entity.

[0043]FIG. 27 is a flow chart describing one embodiment of a process fordetermining the members of a group.

[0044]FIG. 28 is a flow chart describing a second embodiment of aprocess for determining the members of a group.

[0045]FIG. 29 is a flow chart describing one embodiment of a process forsubscribing to a group.

[0046]FIG. 30 is a flow chart describing one embodiment of a process forun-subscribing from a group.

[0047]FIG. 31 is a flow chart describing one embodiment of a process forexpanding a group.

[0048]FIG. 32 is a flow chart describing an overview of an exemplarprocess for adding and removing auxiliary classes.

[0049]FIG. 33 is a flow chart describing one embodiment of a process forremoving auxiliary classes.

[0050]FIG. 34 is a flow chart describing one embodiment of a process foradding auxiliary classes.

[0051]FIG. 35 is a flowchart describing a process for responding to aclient's request.

[0052]FIG. 36 is a flowchart describing a process for responding to arequest for a pre-processing application.

[0053]FIG. 37 is a block diagram illustrating an identity server'sprogram service and XML data registry.

[0054]FIG. 38 is a flowchart describing a process for translating arequest.

[0055]FIG. 39 is a flowchart describing a process for preparing OutputXML.

[0056]FIG. 40 is a flowchart describing a process for responding to arequest for a post-processing application.

[0057]FIG. 41 is a flowchart describing a process for preparing aclient-side response.

[0058]FIG. 42 is a flowchart describing a process for preparing aserver-side response.

[0059]FIG. 43 is a flowchart describing a process for identifying an XMLtemplate for a navigation bar.

[0060]FIG. 44 is a block diagram representing a thread of execution.

[0061]FIG. 45 is a flowchart describing a process for performingrequest-based caching.

[0062]FIG. 46 is a block diagram showing an interconnection between twoidentity servers.

[0063]FIG. 47 is a flowchart describing a process for servicing arequest that requires operations to be performed by multiple identityservers.

[0064]FIG. 48 is a flowchart describing a process for servicing a localcomponent of a remote request.

[0065]FIG. 49 is a flowchart describing a process for servicing a remotecomponent of a remote request.

[0066]FIG. 50 is a flowchart describing a process for flushing localcaches.

[0067]FIG. 51 is a flowchart describing a process for flushing remotecaches.

[0068]FIG. 52 is a block diagram of an identity server coupled to anauthority that issues certificates.

[0069]FIG. 53 is a flowchart describing a process for processing acertificate related request.

[0070]FIG. 54 is a flowchart describing a process for responding to acertificate enrollment request.

[0071]FIG. 55 is a flowchart describing a process for obtaining acertificate.

[0072]FIG. 56 is a flowchart describing a process for responding to acertificate renewal request.

[0073]FIG. 57 is a flowchart describing a process for obtaining anautomatic certificate renewal.

[0074]FIG. 58 is a flowchart describing a process for responding to acertificate revocation request.

[0075]FIG. 59 is a flowchart describing a process for obtaining acertificate revocation.

[0076]FIG. 59A is a flow chart describing one embodiment of a processfor obtaining and maintaining real time certificate status.

[0077]FIG. 59B is a flow chart describing one embodiment of a processfor exporting a certificate.

[0078]FIG. 59C is a flow chart describing one embodiment of a processfor displaying certificate information.

[0079]FIG. 60 is a flow chart describing a process for creating a policydomain.

[0080]FIG. 61 is a flow chart describing a process for adding anauthorization rule.

[0081]FIG. 62 is a flow chart describing a process for adding headervariables to an HTTP request.

[0082]FIG. 63 is a flow chart describing a process for adding anauthentication rule.

[0083]FIG. 64 is a flow chart describing a process for creating apolicy.

[0084]FIG. 65 is a flow chart describing an exemplar process performedby the Access System of one embodiment of the present invention.

[0085]FIG. 66 is a flow chart describing a process for determiningwhether a particular resource is protected.

[0086]FIG. 67 is a flow chart describing a process for mapping aresource with a policy domain.

[0087]FIG. 68 is a flow chart describing a process for retrieving firstand second level authentication rules.

[0088]FIG. 69 is a flow chart describing a process for determiningwhether a resource URL matches a specific policy URL.

[0089]FIG. 70 is a flow chart describing authentication.

[0090]FIG. 71 is a block diagram depicting the components of oneembodiment of a cookie.

[0091]FIG. 72 is a flowchart describing a process for authorization.

[0092]FIG. 73 is a flow chart describing a process for obtaining firstand second level authorization rules from a Directory Server.

[0093]FIG. 74 is a flow chart describing a process for evaluating anauthorization rule.

DETAILED DESCRIPTION

[0094]FIG. 1 depicts an access management system, which providesidentity management services and/or access management services for anetwork. The identity management portion of the system (hereinafter “theIdentity System”) manages identity profiles, while the access managementportion of the system (hereinafter “the Access System”) providessecurity for resources across one or more Web Servers. A key feature ofone embodiment of this system is the centralization of the repositoriesfor policies and user identity profiles, while decentralizing theiradministration. That is, one embodiment of the system centralizes thepolicy and identity repositories by building them on a directory servicetechnology. The system decentralizes their administration by hierarchydelegating administrative roles. Although the system of FIG. 1 includesan Identity System and an Access System, other embodiments may onlyinclude an Identity System or only include an Access System.

[0095]FIG. 1 is a block diagram depicting one embodiment for deployingan integrated Identity System and Access System. FIG. 1 shows webbrowsers 12 and 14 accessing Web Server 18 and/or Web Server 20 vianetwork 16. One example of a network is the Internet. In one embodiment,web browsers 12 and 14 are standard web browsers known in the artrunning on any suitable type of computer. FIG. 1 depicts web browsers 12and 14 communicating with Web Server 18 and Web Server 20 using HTTPover the Internet; however, other protocols and networks can also beused.

[0096] Web Server 18 is a standard Web Server known in the art andprovides an end user with access to various resources via network 16.One embodiment includes two firewalls. A first firewall (see dottedlines) is connected between network 16 and Web Server 18. A secondfirewall (see dotted lines) is connected between Web Servers 16 and 18and Access Server 34/Identity Server 40.

[0097]FIG. 1 shows two types of resources: resource 22 and resource 24.Resource 22 is external to Web Server 18 but can be accessed through WebServer 18. Resource 24 is located on Web Server 18. A resource can beanything that is possible to address with a uniform resource locator(URL, see RFC 1738). A resource can include a web page, softwareapplication, file, database, directory, a data unit, etc. In oneembodiment, a resource is anything accessible to a user on a network.The network could be the Internet, a LAN, a WAN, or any other type ofnetwork. Table 1, below, provides examples of resources and at least aportion of their respective URL syntax: Resource URL Encoding Directory/Sales/ HTML Page /Sales/Collateral/index.html CGI Script with no query/cgi-bin/testscript.cgi CGI Script with query/cgi_bin/testscript.cgi?button=on Application /apps/myapp.exe

[0098] A URL includes two main components: a protocol identifier and aresource name separated from the protocol identifier by a colon and twoforward slashes. The protocol identifier indicates the protocol used tofetch the named resource. Examples of protocols include HTTP, FTP,Gopher, File and News. The resource name is the complete address to theresource. The format of the resource name depends on the protocol. ForHTTP, the resource name includes a host name, a file name, a port number(optional) and a reference (optional). The host name is the name of themachine on which the resource resides. The file name is the path name tothe file on the machine. The port number is the number of the port towhich to connect. A reference is a named anchor within a resource thatusually identifies a specific location within a file. Consider thefollowing URL:

[0099] “http://www.oblix.com/oblix/sales/index.html.”

[0100] The string “http” is the protocol identifier. The string“www.oblix.com” is the host name. The string “/oblix/sales/index.html”is the file name.

[0101] A complete path, or a cropped portion thereof, is called a URLprefix. In the URL above, the string “/oblix/sales/index.html” is a URLprefix and the string “/oblix” is also a URL prefix. The portion of theURL to the right of the host name and to the left of a query string(e.g. to the left of a question mark, if there is a query string) iscalled the absolute path. In the URL above, “/oblix/sales/index.html” isthe absolute path. A URL can also include query data, which is typicallyinformation following a question mark. For example, in the URL:

[0102] http://www.oblix.com/oblix/sales/index.html?user=smith&dept=sales

[0103] the query data is “user=smith&dept=sales.” Although thediscussion herein refers to URLs to identify a resource, otheridentifiers can also be used within the spirit of the present invention.

[0104]FIG. 1 shows Web Server 18 including Web Gate 28, which is asoftware module. In one embodiment, Web Gate 28 is a plug-in to WebServer 18. Web Gate 28 communicates with Access Server 34. Access Server34 communicates with Directory Server 36.

[0105] The Access System includes Access Server 34, Web Gate 28, andDirectory Server 36. Access Server 34 provides authentication,authorization, auditing logging services. It further provides foridentity profiles to be used across multiple domains and Web Serversfrom a single web-based authentication (sign-on). Web Gate 28 acts as aninterface between Web Server 18 and Access Server 34. Web Gate 28intercepts requests from users for resources 22 and 24, and authorizesthem via Access Server 34. Access Server 34 is able to providecentralized authentication, authorization, and auditing services forresources hosted on or available to Web Server 18 and other Web Servers.

[0106] The Identity System includes Web Pass 38, Identity Server 40 andDirectory Server 36. Identity Server 40 manages identity profiles. Anidentity profile is a set of information associated with a particularentity (e.g. user, group, organization, etc.). The data elements of theidentity profile are called attributes, which are discussed in moredetail below. An attribute may include a name, value and accesscriteria. The Identity Server includes three main applications, whicheffectively handle the identity profiles and privileges of the userpopulation: User Manager 42, Group Manager 44, and Organization Manager46. User Manager 42 manages the identity profiles for individual users.Group Manager 44 manages identity profiles for groups. OrganizationManager 46 manages identity profiles for organizations. Identity Server40 also includes Publisher 48, an application that enables entities toquickly locate and graphically view information stored by DirectoryServer 36. In one embodiment, Web Pass 38 is a Web Server plug-in thatsends information back and forth between Identity Server 40 and the WebServer 20, creating a three-tier architecture. The Identity System alsoprovides a Certificate Processing Server (not shown in FIG. 1) formanaging digital certificates.

[0107] User Manager 42 handles the functions related to user identitiesand access privileges, including creation and deletion of user identityprofiles, modification of user identity profile data, determination ofaccess privileges, and credentials management of both passwords anddigital certificates. With User Manager 42, the create, delete, andmodify functions of user identity management can be set as flexible,multi-step workflows. Each business can customize its own approval,setup, and management processes and have multiple processes fordifferent kinds of users.

[0108] Multi-level delegation features also simplify individual usermanagement. Companies can assign the responsibility for maintaining useridentity data to the people closest to it. For example, individual userscan be allowed to: (1) add themselves to the user directory by fillingout customized forms, (2) modify personal or professional informationabout themselves (such as addresses, personal preferences, or namechanges), (3) change a piece of information in their identity profilesthat can determine their access rights, or (4) allow someone else to login as their temporary substitute while they are out of the office or onvacation. Likewise, any number of delegated administrators (both insideand outside the company) can be given the authority to: (1) create anddelete users in the user directory, (2) approve a change that a user hasrequested, and (3) change the information about users to grant or revokeservices. An administrator can be delegated any allowed degree ofresponsibility. For example, a company might decide that only IT staffcan assign application access, whereas department managers can add newusers.

[0109] External legacy systems-such as human resource managementsystems—can be allowed to trigger automated workflows. With thisfeature, a new user could be created, a departing employee could bedeleted, or certain services could be granted or revoked following anevent change in an external system.

[0110] The Identity System also provides for self-registration. UserManager 42 enables an individual to self-register in situations whenit's appropriate. User Manager 42 then authorizes delegatedadministrators to verify the individual's information and approve ordeny the registration requests. In one embodiment, self-registration isdefined by a customizable, multi-step workflow. This concept isdiscussed below.

[0111] Group Manager 44 allows entities to create, delete and managegroups of users who need identical access privileges to a specificresource or set of resources. Managing and controlling privileges for agroup of related people-rather than handling their needsindividually-yield valuable economies of scale. Group Manager 44 meets awide range of e-business needs: easy creation, maintenance, and deletionof permanent and ad hoc groups of users who may be allowed or deniedaccess to particular resources; modification and adaptation of groupsand their access privileges with minimal disruption to the directoryserver's underlying schema; efficient addition and deletion of usersfrom established groups; and delegation of administrative responsibilityfor group membership and subscription requests and approvals.

[0112] With Group Manager 44, companies (or other entities) can allowindividual users to do the following: (1) self-subscribe to andunsubscribe from groups, (2) view the groups that they are eligible tojoin or have joined, and (3) request subscription to groups that haveaccess to the applications they need. Multi-step workflows can thendefine which users must obtain approval before being added to a groupand which can be added instantly. Group Manager 44 also lets companiesform dynamic groups specified by an LDAP filter. The ability to createand use dynamic groups is extremely valuable because it eliminates theadministrative headache of continually keeping individual, staticmembership up-to-date. With dynamic group management features, users canbe automatically added or removed if they meet the criteria specified bythe LDAP filter. Dynamic groups also greatly enhance security sincechanges in user identities that disqualify someone from membership in agroup are automatically reflected in the dynamic group membership.

[0113] The third application in the Identity System, OrganizationManager 46, streamlines the management of large numbers of organizationswithin an e-business network, including partners, suppliers, or evenmajor internal organizations such as sales offices and business units.Certain infrastructure security and management operations are besthandled—or can only be handled—at the highest organizational unit levelrather than at the individual or group level. Like User Manager andGroup Manager, this application relies on multi-step workflow anddelegation capabilities. Organization Manager handles the followingadministrative tasks: (1) organization lifecycle management, wherebycompanies can create, register, and delete organizations in theirsystems using customizable workflows; (2) maintenance of organizationprofiles on an attribute-by-attribute basis through self-service,delegated administration and system-initiated activities; (3)organization self-registration, whereby organizations such as businesspartners, customers and suppliers can self-generate a request to beadded to the e-business network; and (4) creation of reusable rules andprocesses through multi-step workflows.

[0114] The system of FIG. 1 can be used to protect a web site, network,Intranet, Extranet, etc. To understand how the system of FIG. 1 protectsa web site (or other structure), it is important to understand theoperation of unprotected web sites. In a typical unprotected web site,end users cause their browsers to send a request to a Web Server. Therequest is usually an HTTP request, which includes a URL. The Web Serverthen translates, or maps, the URL into a file system's name space andlocates the matching resource. The resource is then returned to thebrowser.

[0115] With the system of FIG. 1 deployed, Web Server 18 (enabled by WebGate 28, Access Server 34, and Directory Server 36) can make informeddecisions based on default and/or specific rules about whether to returnrequested resources to an end user. The rules are evaluated based on theend user's identity profile, which is managed by the Identity System. Inone embodiment of the present invention, the general method proceeds asfollows. An end user enters a URL or an identification of a requestedresource residing in a protected policy domain. The user's browser sendsthe URL as part of an HTTP request to Web Server 18. Web Gate 28intercepts the request. If the end user has not already beenauthenticated, Web Gate 28 causes Web Server 18 to issue a challenge tothe browser for log-on information. The received log-on information isthen passed back to Web Server 18 and on to Web Gate 28.

[0116] Web Gate 28 in turn makes an authentication request to AccessServer 34, which determines whether the user's supplied log-oninformation is authentic or not. Access Server 34 performs theauthentication by accessing attributes of the user's identity profileand the resource's authentication criteria stored on Directory Server36. If the user's supplied log-on information satisfies theauthentication criteria, the process flows as described below;otherwise, the end user is notified that access to the requestedresource is denied and the process halts. After authenticating the user,Web Gate 28 queries Access Server 34 about whether the user isauthorized to access the resource requested. Access Server 34 in turnqueries Directory Server 36 for the appropriate authorization criteriafor the requested resource. Access Server 34 retrieves the authorizationcriteria for the resource and answers Web Gate 28's authorization query,based on the resource's authorization criteria and the user's identityprofile. If the user is authorized, the user is granted access to theresource; otherwise, the user's request is denied. Various alternativesto the above described flow are also within the spirit and scope of thepresent invention.

[0117] Authentication and Authorization decisions are based on policydomains and policies. A policy domain is a logical grouping of WebServer host ID's, host names, URL prefixes, and rules. Host names andURL prefixes specify the course-grain portion of the web name space agiven policy domain protects. Rules specify the conditions in whichaccess to requested resources is allowed or denied, and to which endusers these conditions apply. Policy domains contain two levels ofrules: first level default rules and second level rules contained inpolicies. First level default rules apply to any resource in a policydomain not associated with a policy.

[0118] A policy is a grouping of a URL pattern, resource type, operationtype (such as a request method), and policy rules. These policy rulesare the second level rules described above. There are two levels ofrules available (first and second levels) for authentication,authorization, and auditing. Policies are always attached to a policydomain and specify the fine-grain portion of a web name space that apolicy protects. In practice, the host names and URL prefixes from thepolicy's policy domain are logically concatenated with the policy's URLpattern. The resulting overall pattern is compared to the incoming URL.If there is a match, then the policy's various rules are evaluated todetermine whether the request should be allowed or denied; if there isnot a match, then default policy domain rules are used.

[0119] The system of FIG. 1 is scalable. There can be many Web Servers,many Access Servers, and many Identity Servers. In one embodiment,Directory Server 36 is an LDAP Directory Server and communicates withother servers/modules using LDAP over SSL. In other embodiments,Directory Server 36 can implement other protocols or can be other typesof data repositories (e.g. SQL, etc.). Many variations of the system ofFIG. 1 can be used with the present invention. For example, instead ofaccessing the system with a web browser, an API can be used.Alternatively, portions of functionality of the present invention cab beseparated into independent programs that can be accessed with a URL.

[0120]FIG. 2 illustrates a high level block diagram of a computer systemthat can be used for the components of the present invention. Thecomputer system in FIG. 2 includes processor unit 50 and main memory 52.Processor unit 50 may contain a single microprocessor, or may contain aplurality of microprocessors for configuring the computer system as amulti-processor system. Main memory 52 stores, in part, instructions anddata for execution by processor unit 50. If the system of the presentinvention is wholly or partially implemented in software, main memory 52can store the executable code when in operation. Main memory 52 mayinclude banks of dynamic random access memory (DRAM) as well as highspeed cache memory.

[0121] The system of FIG. 2 further includes mass storage device 54,peripheral device(s) 56, user input device(s) 60, portable storagemedium drive(s) 62, graphics subsystem 64, and output display 66. Forpurposes of simplicity, the components shown in FIG. 2 are depicted asbeing connected via a single bus 68. However, the components may beconnected through one or more data transport means. For example,processor unit 50 and main memory 52 may be connected via a localmicroprocessor bus, and the mass storage device 54, peripheral device(s)56, portable storage medium drive(s) 62, and graphics subsystem 64 maybe connected via one or more input/output (I/O) buses. Mass storagedevice 54, which may be implemented with a magnetic disk drive or anoptical disk drive, is a non-volatile storage device for storing dataand instructions for use by processor unit 50. In one embodiment, massstorage device 54 stores the system software for implementing thepresent invention for purposes of loading to main memory 52.

[0122] Portable storage medium drive 62 operates in conjunction with aportable non-volatile storage medium, such as a floppy disk, to inputand output data and code to and from the computer system of FIG. 2. Inone embodiment, the system software for implementing the presentinvention is stored on such a portable medium, and is input to thecomputer system via the portable storage medium drive 62. Peripheraldevice(s) 56 may include any type of computer support device, such as aninput/output (I/O) interface, to add additional functionality to thecomputer system. For example, peripheral device(s) 56 may include anetwork interface for connecting the computer system to a network, amodem, a router, etc.

[0123] User input device(s) 60 provide a portion of a user interface.User input device(s) 60 may include an alpha-numeric keypad forinputting alpha-numeric and other information, or a pointing device,such as a mouse, a trackball, stylus, or cursor direction keys. In orderto display textual and graphical information, the computer system ofFIG. 2 includes graphics subsystem 64 and output display 66. Outputdisplay 66 may include a cathode ray tube (CRT) display, liquid crystaldisplay (LCD) or other suitable display device. Graphics subsystem 64receives textual and graphical information, and processes theinformation for output to display 66. Additionally, the system of FIG. 2includes output devices 58. Examples of suitable output devices includespeakers, printers, network interfaces, monitors, etc.

[0124] The components contained in the computer system of FIG. 2 arethose typically found in computer systems suitable for use with thepresent invention, and are intended to represent a broad category ofsuch computer components that are well known in the art. Thus, thecomputer system of FIG. 2 can be a personal computer, handheld computingdevice, Internet-enabled telephone, workstation, server, minicomputer,mainframe computer, or any other computing device. The computer can alsoinclude different bus configurations, networked platforms,multi-processor platforms, etc. Various operating systems can be usedincluding Unix, Linux, Windows, Macintosh OS, Palm OS, and othersuitable operating systems.

[0125]FIG. 1 shows Web Server 20 being in communication with IdentityServer 40, via Web Pass 38. In one embodiment of the present invention,data is transferred between a web server and Identity Server 40 usingblob data transfers. One version of a blob data transfer contains thefollowing fields: (1) Overall Message Length—containing the number ofbytes in the overall blob data transfer; (2) ProtocolVersion—identifying the protocol version of the blob data transfer; (3)Sequence Number—identifying the position of the blob data transfer in aset of blob data transfers; (4) Opcode—identifying the operation to beperformed with the blob data; and (5) Actual Message—containing the dataintended to be transferred for an associated application.

[0126] Possible opcodes that can be employed in the blob data transferopcode field include: (1) indicating that the blob data transfer is tobe employed by Identity Server 40; and (2) indicating that this data isto be employed by a Web Server 20 in a configuration process. In oneembodiment of the present invention, the Actual Message is presented ina key-val-map format having the following syntax:{length}key=val{length}key=val{length}key=val . . . .

[0127]FIG. 1 shows Identity Server 40 communicating with DirectoryServer 36. The system can also support multiple directory servers (orother types of data stores). FIG. 3 depicts an exemplar architecture forsupporting multiple directory servers based on the notion of abstractingdatabase objects and separating database clients from the actualdatabase access functionalities. By doing so, clients can be implementedin a database independent fashion. Database manager 120 is the centralplace where all database clients interface to access the data stores. Inone embodiment, there is one database manager 120 for all clients.

[0128] When database manager 120 starts, it will read the directoryserver configuration file(s) and insert corresponding profile and agentobjects to its internal tables for later reference. FIG. 3 showsdatabase manager 120 in communication with profiles 122, 124, 126 and128. Each profile corresponds to an agent. For example, profile 122corresponds to agent 130, profile 124 corresponds to agent 132, profile126 corresponds to agent 134, and profile 128 corresponds to agent 136.Each agent is associated with a connection manager and a data store. Forexample, agent 130 is associated with connection manager 140 and datastore 36 a. Agent 132 is associated with connection manager 142 and datastore 36 b. Agent 134 is associated with connection manager 144 and datastore 36 c. Agent 136 is associated with connection manager 146 and datastore 36 d. In one embodiment, each of the data stores are LDAPdirectory servers with LDAP directories. In other embodiments, one ormore of the data stores are LDAP directories and one or more of the datastores are other types of data stores (e.g. SQL servers) or others. Infurther embodiments, none of the data stores are LDAP directories.

[0129] Each of the profiles represents configuration information for theassociated data store. This includes, among other things, host name,port number, name space, login name (also called an ID), password, andsupport operations. There is a one-to-one mapping between a profile andagent. One of the most important methods exposed by a profile is themethod “IsSupported.” Database manager 120 calls this method todetermine whether a proposed data store access request can be performedby the data store associated with the profile. The method will return afalse if any of the following are met: (1) the configured profile is notenabled, (2) the database type (e.g. LDAP) of the access request is notthe same as the data store for that profile, (3) the type of operationis not supported by the data store, (4) the target user identificationhas no overlap with the profile's (and data store's) name space, or (5)the target's user identification is above the profile's (and datastore's) name space and the target operation is not SEARCH.

[0130] The Agent is the object responsible for all the interaction withthe data stores. Each agent includes a Connection Manager, whichmaintains the connection with the associated data store. The agents areresponsible for converting the native data store entries to the formatexpected by the application.

[0131] Database clients interact with database manager 120 to accomplishany database operation. Database manager 120, in turn, interacts withthe profiles to determine which data stores can service the databaseoperation. A database proxy 154 is created to service a particulardatabase request. Database proxy 154 communicates directly to the Agentsfor the data stores that can service the request. The database clientthen interacts directly with proxy 154 to access the appropriate datastores. Thus, database proxy 154 is a dynamic object which databasemanager 120 creates every time a database request is made.

[0132] Database proxy 154 encapsulates the supporting agent objects forthe particular operation. It also acts as a storage area where inputparameters and output results are stored. Each database proxy objectexposes its methods and input parameters. These parameters includesearch base, object class, auxiliary class, filter, search scope,attributes and entry. After a database client sets all the parameters,the client calls the execute method of the proxy to invoke the databaseoperation. The client then calls the database proxy GetResults method toretrieve the operations results.

[0133]FIG. 3 shows database proxy 154 in dotted lines to indicate thatit is created for a particular request. When the request is completed,the proxy is terminated. The proxy communicates directly with theappropriate agents for accessing the appropriate data stores. FIG. 3shows one example of a database proxy being created to access data indata stores 36a and 36b.

[0134]FIG. 4 is a flowchart describing the process for performing a dataoperation when one or more data stores are supported. In step 170,application 150 calls baseDB 152. Application 150 can be User Manager42, Group Manager 44, Organization Manager 46, etc. BaseDB 152 is anobject used by the application to access a data store. In oneembodiment, baseDB 152 includes sub-objects. There is one sub-object foreach application.

[0135] BaseDB 152 calls database manager 120 in step 172, indicating theoperation and search base for the data operation. In step 174, databasemanager 120 consults each of the profiles to determine which data storecan support the operation. That is, each data store is a particular typeof data store, has its own set of operations that it supports, and hasits own search base that it supports. In step 176, each of the profilesindicates whether they can service the request based on whether theabove mentioned criteria match the request. In step 178, databasemanager 120 creates proxy 154. Note that proxy 154 is for this oneparticular request and will be terminated at the end of the request.

[0136] In one example, it is assumed that profiles 122 and 124 indicatethat their associated data stores can service the operation, butprofiles 126 and 128 report that their associated data stores cannotservice the operation. Therefore, proxy 154 will be set up tocommunicate with agents 130 and 132, as depicted in FIG. 3.

[0137] In step 180, proxy 154 is provided with pointers to theappropriate agents, as depicted in FIG. 3. In step 182, baseDB 152 callsproxy 154 to indicate the one or more database access operationsrequested. In step 184, proxy 154 communicates the appropriate requestinformation to the appropriate agents. In step 186, the appropriateagents perform appropriate database accesses using their respectiveconnection managers. In step 188, the agents convert the data from thenative format of the data store to the format expected by application150. In some embodiments, conversion is not necessary. In step 190, eachof the agents returns the results to proxy 154. In step 192, proxy 154combines the results from the various data stores into one set ofresults. In one embodiment, step 192 is skipped and the results are notcombined. In step 194, the results are then provided to userDB 152. Instep 196, database proxy 154 is terminated. In step 198, the results arereported back to application 150. In this manner, application 150 isinsulated from the data access layer (which includes database proxy,database manager and any other components below the database manager120, as depicted in FIG. 3). Note that when the access to the datastores includes a read operation, the reporting of results will likelyinclude the data that was read. If the access was for a write operation,the reporting of results can include a confirmation of the writeoperation or a reporting of the data that was written. In someembodiments, the failure to notify of an error during a write operationcan be considered as reporting a successful result of the writeoperation.

[0138] The basic unit of information store in a directory is called anentry, which is a collection of information about an object. Theinformation in an entry often describes a real-world object such as aperson, but this is not required. A typical directory includes manyentries that correspond to people, departments, servers, printers, andother real-world objects in the organization served by the directory.

[0139] An entry is composed of a set of attributes, each of whichdescribes one particular trait of the object. Each attribute has a type,one or more values, and associated access criteria. The type describesthe kind of information contained in the attribute, and the valuecontains the actual data.

[0140] An entry in the directory has a set of attribute that arerequired and a set of attribute that are allowed. For example, an entrydescribing a person is required to have a cn (common name) attribute andan sn (surname) attribute. One example of an allowed attribute may be anickname. Any attribute not explicitly required or allowed isprohibited. The collections of all information about required andallowed attributes are called the directory schemas.

[0141] Examples of attributes stored in a user identity profile include:first name, middle name, last name, title, email address, telephonenumber, fax number, mobile telephone number, pager number, pager emailaddress, identification of work facility, building number, floor number,mailing address, room number, mail stop, manager, direct reports,administrator, organization that the user works for, department number,department URL, skills, projects currently working on, past projects,home telephone, home address, birthday, previous employers and anythingelse desired to be stored by an administrator. Examples of attributesstored in a group identity profile include: owner, name, description,static members, dynamic member rule, subscription policies, etc.Examples of attributes stored in a user organization identity profileinclude: owner, name, description, business category, address, country,etc. In other embodiments, less or more than the above-listedinformation is stored.

[0142]FIG. 5 depicts an exemplar directory tree that can be stored onDirectory Server 36. Each node on the tree is an entry in the directorystructure that includes an identity profile. In one embodiment, theentity can be a user, group or organization. Node 230 is the highestnode on the tree and represents an entity responsible for the directorystructure. In one example, an entity may set up an Extranet and grantExtranet access to many different companies. The entity setting up theExtranet is node 230. Each of the companies with Extranet access wouldhave a node at a level below node 230. For example, company A (node 232)and company B (node 234) are directly below node 230. Each company maybe broken up into organizations. The organizations could be departmentsin the company or logical groups to help manage the users. For example,FIG. 5 shows company A broken up into two organizations: organization Awith node 236 and organization B with node 238. Company B is shown to bebroken up into two organizations: organization C with node 240 andorganization D with node 242. FIG. 5 shows organization A having two endusers: employee 1 with node 250 and employee 2 with node 252.Organization B is shown with two end users: employee 3 with node 254 andemployee 4 with node 256. Organization C is shown with two end users:employee 5 with node 258 and employee 6 with node 260. Organization D isshown with two end users: employee 7 with node 262 and employee 8 withnode 264.

[0143] Each entity has a distinguished name (DN), which uniquelyidentifies the node. In one embodiment, each entry also has a relativename, which is different from all other relevant names on the same levelof the hierarchy. In one implementation, the distinguished name (DN)comprises a union of the relative names up the tree through to theentity. For example, the distinguished name of employee 1 (node 250) is

DN=CN=Empl, OU=OrgA, O=CompanyA, DC=entity,

[0144] where:

[0145] DC=Domain Component

[0146] O=Organization

[0147] OU=Organizational Unit

[0148] CN=common name.

[0149]FIG. 5 shows a hierarchical tree. Some organizations employ fat orflat trees for ease of maintenance. A flat directory tree is a directoryinformation tree that does not have any hierarchy. All of the nodes areleaf nodes (nodes without any child nodes). A fat directory tree is atree that has a large number of nodes at any given level in a directoryinformation tree. One advantage of a fat or flat tree is usermaintenance. For example, if an employee moves to a new group, the nodemust be moved to a new container if the tree is not flat or fat. Bymoving the node to a new container, the distinguished name for the nodechanges and all certificates become void. One drawback of flat or fattrees is that the organization loses the benefits of having a logicaldirectory, such as using the logical directory to determine who hasaccess to which nodes. To remedy this, the Identity System includespartition support for fat and flat tree directories using filters. Froma configuration page, an attribute can be configured to be accessible(read, modify, etc.,) based on a two part filter. The first component inthe filter identifies a top node in the directory. The filter will onlyapply to those entities at or below that top node. The second componentof the filter is an LDAP filter which defines who can access theattribute. This two component filter can be applied on an attribute byattribute basis.

[0150] There are many ways for an entity to access and use the IdentitySystem. In one embodiment, the entity can access the Identity Systemsservices using a browser. In other embodiments, XML documents and API'scan be used to access the services of the Identity System. For example,an entity can use a browser by pointing the browser to Identity Server40. The user will then be provided with a login page to enter the user'sID, password, type of user and application requested (optional). Uponfilling out that information, the user will be authenticated andauthorized (by the Access System) to use the Identity System, asdescribed below. Alternatively, the Access System can be bypassed (orthere may be no Access System) and the Identity System authenticates theuser.

[0151]FIG. 6 is a flowchart, which describes a process of entering theIdentity System. In step 300 the user requests access to the IdentitySystem. For example, the user can point a browser to Identity Server 40.After being provided with a login page, the user fills in the logininformation, and that information is sent back to the system. If thereis an Access System, as described below, then the user will beauthenticated and authorized by the Access System. After authorization,the request will be redirected from the Access System to Web Server 20(see FIG. 1). If there is no Access System, or if the Access System isnot providing authentication and/or authorization services, the browsercan initially be pointed directly to Web Server 20. Other alternativescan also be supported. Upon the request being sent to Web Server 20, therequest will be intercepted by Web Pass 38 in step 302. In step 304, itis determined whether there is an Identity System UidCookie. TheUidCookie is stored on the user's system and can be provided with therequest.

[0152]FIG. 7 depicts an example of UidCookie 360. A cookie isinformation that a web page, system or resource stores on a clientdevice. In some embodiments it can represent information about the user,regardless of where it is stored and in what format. This cookieincludes at least three components: Uid 362, IP address 364 andtimestamp 366. Uid 362 stores the user identification for the entitytrying to access the Identity System. IP address 364 is the IP addressof the machine that the user is currently using. Timestamp 366 indicatesthe time that the cookie was initially created. Some embodiments usetimestamp 366 to limit the life of the cookie. Some embodiments do notuse timestamp 366. In one embodiment, the cookie is encrypted.

[0153] If, in step 304, it is determined that a valid UidCookie exists,then, in step 306, the user is given access to the Identity Systemapplication requested. The Uid from the cookie is used as the useridentification upon entering the Identity System. If the valid UidCookiedoes not exist (step 304), then it is determined whether a useridentification was received in a header variable. In one embodimentusing an integrated Access and Identity System, a user's request toaccess the Identity System will be authenticated and authorized by theAccess System. After authentication and/or authorization, the HTTPrequest will be redirected to the Identity System. This redirected HTTPrequest will include a header variable labeled as “userAuth.” The dataassociated with this header variable will indicate the useridentification for the user. If the user identification was in a headervariable then a UidCookie is created in step 310 and that useridentification is added to the UidCookie. Subsequent to step 310, theuser is provided access to the Identity System in step 306.

[0154] If the user identification was not in a header variable, then thesystem attempts to authenticate the user in step 312. That is, theuser's user name and password provided by the login page are used toaccess Directory Server 36 in order to authenticate the user. Moreinformation about authentication is described below. If the user isproperly authenticated, then a UidCookie is created in step 316. Duringan authentication process, the user's ID and password were used toaccess the user's identity profile in Directory Server 36. That identityprofile will include a user identification, which is added to theUidCookie in step 316. In one embodiment, the user identification is theuser's distinguished name. In step 318, the user is provided access tothe Identity System. If the user was not properly authenticated, thenthe user is denied access to the Identity System in step 320.

[0155] As discussed above, when requesting access to the IdentitySystem, the user selects which of the Identity System applications (UserManager 42, Group Manager 44, Organization Manager 46 or Publisher 48)the user wishes to access. In one embodiment, the login page for theIdentity System will request an ID, a password, an indication of theapplication requested and an indication of a role (discussed below).After appropriate authentication and authorization, the user is providedwith a home page for User Manager 42, a home page for Group Manager 44,a home page for Organization Manager 46 or a home page for Publisher 48,depending upon which application was selected by the user. From the homepage, the user can access the various services of the application.

[0156]FIG. 8 graphically depicts the various services provided by UserManager 42. Each of these services can be accessed from the User Managerhome page. For example, in one embodiment, the home page will include anapplication selector 402, search tool 404, My Identity tab 406, CreateUser Identity tab 408, Deactivate User Identity tab 410, SubstituteRights tab 412, Requests tab 414 and Configure tab 416. Applicationselector 402 lets the user change applications from the User Manager toeither the Group Manager, Object Manager or Publisher. In oneembodiment, application selector 402 is a drop down menu. Search tool404 enables a user to provide search information in order to search thedirectory for a set of one or more user identity profiles.

[0157] By selecting My Identity tab 406, a user is provided with theinformation stored in that user's identity profile. Create User Identitytab 408 allows a user with the appropriate privileges to create a newuser identity profile (e.g. with a workflow). Deactivate User Identitytab 410 allows a user with proper privileges to remove an identityprofile from the directory. Substitute Rights tab 412 allows the user toindicate who can proxy that user and allows the user to be a proxy forsomeone else. Request tab 414 allows a user to monitor workflows thatare in progress or recently completed. Depending on the user'sprivileges, by selecting request tab 414, the user can see all workflowsthat involve that user, that are started by that user, that affect thatuser or that the user has privileges to view. Request tab 414 willindicate workflows for which there is an outstanding action to be doneby the current user. The user can select that workflow and perform thetask.

[0158] Configure tab 416 allows a user to configure various options forUser Manger 42. The user must have sufficient privileges to accessConfigure tab 416. The user can perform attribute access control,delegate administration, define workflows and set the search base.Attribute access control includes controlling who has view and modifypermissions for each attribute. Attributes can be set at any and alllevels in an organization. The configuration also allows thespecification of an e-mail notification list when a change to anattribute is requested. Delegation administration includes delegatingadministrative tasks to local administrators. An entity can choose whatrights to delegate, whom to delegate to, and the scope to delegate.Workflow definition includes defining workflows for a particularorganization, defining who will be responsible for the workflow actionsand/or defining who will be receiving notifications for the workflowactions. Setting the search base includes setting the search base for aparticular organization, person or set of persons. This will localizeaccess to ensure security.

[0159]FIG. 9 depicts the various services provided by Group Manager 44.Once an entity is at the Group Manager home page, the entity can accessthe application selector 430, search tool 432, My Groups tab 434, CreateGroups tab 436, Request tab 438 and Configure tab 440. My Groups tab 434indicates the groups of which the entity is a member. By selecting anyof the groups identified by My Groups tab 434 or Search Tool 432, theuser will be provided with the identity profile page for that particulargroup. From the profile page, the group can be modified or deleted.Create groups tab 436 allows the user to create a new group. Request tab438 provides the user with access to currently pending and recentlyfinished workflows that involve groups. Configure tab 440 allows theuser to configure various information about groups in the Group Manager.While viewing the identity profile for a group, the entity can modifythat profile if the entity has appropriate privileges.

[0160] Configure tab 440 allows an entity to provide attribute accesscontrol, delegate rights, define workflows and expand dynamic groups.Attribute access control includes controlling who has view and modifypermissions for each attribute in group identity profiles. Additionally,e-mail notification lists can be created which are used to notifyentities when a change to an attribute is requested. Administrationtasks can be delegated to local administrators. An entity can choosewhat rights to delegate, who to delegate to, and what the scope of thedelegation is. Workflow definition includes defining the workflows for aparticular group. This includes defining who is responsible for theworkflow actions and who will be receiving notifications for workflowactions. Expanding dynamic groups will be discussed below. Note thatsome of the tabs and services may not be available to all entities,depending upon the privileges of those entities.

[0161]FIG. 10 depicts the services provided by Organization Manager 46.Organization manager 46 provides functionality to create, modify, deleteand manage organizational objects. From the home page for OrganizationManager 46, a user is provided with an application selector 442, searchtool 444, Create Organizational Profile tab 446, Request tab 448 andConfigure tab 450. Application selector 442 allows the user to select adifferent application to access. Search tool 444 provides a user withthe ability to enter search terms in order to search for one or moreorganizational objects. After performing a search, the user will beprovided with a list of organizational objects meeting the searchrequirements. User can select any of these objects to view, modify ordelete, if the user has sufficient privileges.

[0162] Create Organizational Profile tab 446 allows a user to create neworganizational objects, if the user has sufficient privileges. Requesttab 448 allows a user to access pending workflows and workflows thathave recently been finished that relate to organizational objects.Access to Request tab 448 can be restricted and/or limited dependingupon users privileges. If a user has a step to perform for a workflow,it will be indicated by Request tab 448.

[0163] Configure tab 450 allows the entity to perform attribute accesscontrol, delegate administration, define workflows and define containerlimits. Attribute access control includes controlling who has view andmodify permissions for each attribute of an organizational identityprofile. In addition, an entity can specify an e-mail notification listwhen a change to an attribute is requested. Delegating administrationincludes delegating administrative tasks to local administrators. Anentity can choose what rights to delegate, whom to delegate to, and thescope of the delegation. Workflow definition includes defining theworkflows for a particular organization, including who will beresponsible for the workflow actions and who will be receivingnotifications for the workflow. Container limits includes controllinghow many objects can be created in an organization. This would alsoinclude defining who will be receiving notifications that a containerlimit has been met, has been violated or is close to being met.

[0164] As discussed above, user identity profiles, group identityprofiles and organization identity profiles all contain attributes. Inthe various services provided by User Manager, Group Manager andOrganization Manager, users with the appropriate privileges canconfigure the rights to access each of the attributes. FIG. 11 is aflowchart describing an exemplar process for configuring rights toaccess attributes. In step 500, a user requests to configure rights. Forexample, the user may select any of the configuration tabs describedabove. In step 502, it is determined whether that user is allowed toconfigure rights to access attributes. If no, the user is not givenaccess to configure any access rights. If the user is allowed toconfigure access rights, then in step 504 the user selects which rightsto configure. In one embodiment, there are choices of three rights:read, write and notify. The notify right is associated with persons whoare notified when an attribute changes.

[0165] In step 506, the particular attributes are selected. For example,in the User Manager, an entity can select the user's name, the user'stelephone number, etc. In step 508, the domain is selected. The domainapplies to the portion of the directory tree that is affected by theconfiguration. That is, only identity profiles in the specified domainare being affected by the current process being performed. In step 510,the users are identified whose rights to access the selected attributesare being affected. The users can be identified by identifying specificnames of users, a group, a class of users, and an owner of the identifyprofile, or an LDAP filter.

[0166] Based on the configuration from the process of FIG. 11, when auser accesses an identity profile, the user's ability to view or modifythat profile will be restricted. FIG. 12 is a flowchart describing theprocess for accessing an identity profile and viewing attributes. Instep 530, the user's browser sends a request to access attributes of atarget directory entry. Alternatively, the user can attempt to accessattributes via means different than a browser (e.g. XML document). Instep 532, the request is received by User Manager 42, Group Manager 44or Organization Manager 46. In step 530, the appropriate manageraccesses the target profile and a source profile on directory server 36.The target profile is the identity profile sought to be viewed. Thesource profile is the identity profile of the user attempting to accessthe target profile. In step 536, the manager determines the accessrights for each of the attributes for the target profile. In step 538,the manager passes the result information for the allowed attributes tothe browser. That is, the manager will determine which attributes theuser may view based on the access information (e.g. from FIG. 11) andthe user's identity profile. All of those attributes that can be viewedare displayed in step 540. Those attributes that can be modified willinclude a “modify” button next to the attribute. Selecting a modifybutton will allow the user to modify the attribute (e.g. change theuser's telephone number, etc.).

[0167] In many implementations of the system of FIG. 1, there is asingle instance of the system that will be running against the directoryserver that holds all the partners/suppliers/customer information in ahierarchical tree. A given user that belongs to one of these partners(or other entities) should be restricted to accessing the informationthat only pertains to that user's company (or other organization). Sodifferent users will have access to a different logical directory.

[0168] To support segmentation of the directory tree, the system employsa policy based search base. As part of the configuration, anadministrator can set up search bases. A particular search base includestwo components. The first component includes identifying to whom thesearch base pertains. The first component can name a single person,multiple persons, a domain in the directory or an LDAP filter. Thesecond component of the search base is to indicate the search baseitself. In one embodiment, indicating the search base includesidentifying a node in the directory tree. That node and all nodes belowthat node in the directory tree will be part of the search base. In someembodiments, the search base can be associated with an object class.

[0169] Once the search base is set up, anyone who the search basepertains to can only access nodes within the search base. Thus, if acompany employs an Extranet and two suppliers have accessed theExtranet, one supplier can be prevented from seeing the profiles aboutthe other supplier using this search base feature. That is, persons incompany A can be configured to only have a search base that includescompany A, and persons in company B can be configured to only have asearch base that includes company B.

[0170] As discussed above, when an entity logs into the Identity System,the entity indicates the entity's role. There are at least six roles:System Administrator, Master Identity Administrator, Master AccessAdministrator, Delegated Access Administrator, Delegated IdentityAdministrator and End User. The System Administrator can perform allAccess System configuration tasks and all Identity System configurationtasks. The Master Identity Administrator can configure access controls,attribute access controls, new user services, workflow definitions,setting the search base, delegating rights, expanding dynamic groups,and setting container limits. The Master Access Administrator canconfigure a web gate, configure an access server, create hostidentifiers, configure users, set-up policies and policy domains, anddelegate rights. The Delegated Identity Administrator is anadministrator who has been delegated rights from the Master IdentityAdministrator. The Delegated Access Administrator can be delegatedrights from a Master Access Administrator. An End User cannot performconfiguration functions. There can also be a delegated admin who cancreate/delete users, add/remove users to/from groups, process workflowsteps, etc.

[0171] A delegated administrator receives rights that were delegated bya master administrator or another delegated administrator. FIG. 13depicts the process of delegating rights to a delegated administrator.In step 580, a request is made to delegate rights. In one embodiment,this request is made by accessing the configure tabs described above. Instep 582, it is determined whether the user requesting to delegate isallowed to delegate. A Master Identity Administrator is allowed todelegate and a Delegated Administrator can delegate if that DelegatedAdministrator has been provided with delegation rights. If the user isnot able to delegate rights, then the process is not completed. If theuser can delegate rights, then in step 584, the rights to be delegatedare selected. In step 586, it is determined whether the person receivingthe delegated right can further delegate that right. That is, can aDelegated Administrator receiving the right then delegate that right toanother Delegated Administrator. In step 588, the attributes associatedwith a delegated right are selected. In step 590, a domain is specified.The domain indicates the area of the directory tree that will beaffected by the delegation of rights. Only profiles within the domainare subject to the delegation of rights. In step 592, the DelegatedAdministrators who will receive the rights being configured areidentified. The administrators can be identified by indicating aparticular name (or other identification), a group or an LDAP ruleindicating who should receive the rights.

[0172] One right that an administrator has and which can be delegated toa Delegated Administrator is the proxy right. The proxy right for personA allows person A to choose another person (e.g. person B) to be a proxyfor person A during a period of time. For example, if a DelegatedAdministrator (or other administrator) is going on vacation, or willotherwise be unavailable to perform its administrative duties, thatDelegated Administrator can identify another person (or persons) who canbe a proxy for that Delegated Administrator. While person B is being aproxy for person A, person B has all the rights and privileges of personA within the Identity System. Person B does not have the rights ofperson A in the Access System. Thus, the Identity System will see personB as person A, but the Access System will see person B as person B.

[0173]FIG. 14 is a flowchart describing the process for enabling othersto be a proxy. The process of FIG. 14 is performed in Substitute Rightstab 412 in the User Manager. In one embodiment, only those entities whoare Delegated Administrators or Master Administrators can perform theprocess of FIG. 14. In another embodiment, any user can choose to beproxied and be a proxy. In step 640, the administrator will request toenable a proxy. In one embodiment, this includes accessing theSubstitute Rights tab 412. Substitute rights tab 412 will provide a listof persons who have been selected for potential proxies.

[0174] In step 644, the administrator can search for more persons to beon the list of potential proxies. In one embodiment, step 644 includesproviding a search tool for a user to search for users. A list ofidentified users is then depicted on the substitute rights tab. Next toeach user's name is a check box. In step 646, the user can select any ofthe users for proxy by selecting the check box. Once a user has beenselected for proxy, then that user can be a proxy for the administratorperforming the process of FIG. 14. However, the user will not become aproxy until the user enacts the proxy right. Thus, selecting the user instep 644 (e.g. checking the box next to the users name) only providesfor the potential for that user to be a proxy. In step 648, all of thepersons who have been selected for potential proxy are notified bye-mail, by a page/tab displaying proxy information or by other means.

[0175]FIG. 15 is a flowchart describing a process that is performed whena user becomes a proxy for another. In step 660, the system receives arequest from a user to become a proxy. In one embodiment, that includesa user selecting Substitute Rights tab 412. In that tab, the systemdisplays a list of all those persons for whom the user can be a proxy.Next to each name will be a check box. In step 662, the user selects theone person for which the user wants to be a proxy (hereinafter referredto as “the person being proxied”). For example, person A accessesSubstitute Rights tab 412 to be a proxy for person B, while person B ison vacation. Person B is the person being proxied. In step 664, the userenacts the proxy right. In one embodiment, step 664 includes selectingan “enact” button. When the user selects the “enact” button, the systemcreates a new cookie on the users' machine called originalUidCookie. TheonginalUidCookie is in the same format as the UidCookie depicted in FIG.7. In one embodiment, the originalUidCookie is an exact copy of theUidCookie currently on the user's machine.

[0176] In step 668, the UidCookie on the user's machine is edited bychanging Uid 362 to equal the user identification for the person beingproxied. In step 670, the user now operates as the person being proxiedin the Identity System. Because the Uid in the Cookie identifies theperson being proxied, the Identity System treats the user as the personbeing proxied. However, the UidCookie is only used by the IdentitySystem, so only the Identity System treats the person as the personbeing proxied. The Access System uses a different cookie (describedbelow), and the Access System's cookie is not edited. Therefore, theAccess System treats the user as himself or herself and not as theperson being proxied. While being a proxy, the user has all the rightsand privileges as the person being proxied. In one embodiment, theprocess of FIG. 15 is performed without the user providing or knowingthe password for the person being proxied and. therefore, withoutauthenticating the password and ID for the person being proxied.

[0177] In one embodiment, step 670 includes receiving a request from theuser (e.g. the entity who is the proxy) to access a service of theIdentity System. In response, the system will access the Uid in thecookie, and use that Uid to access attributes, group memberships andorganizations memberships for the identity profile of the person beingproxied. Based on those attributes, the user will or will not beprovided access to the requested service.

[0178] In step 672 of FIG. 15, the user de-enacts the proxy right. Inone embodiment, this is performed by accessing the substitute rights taband clicking on a “de-enact” button. After de-enacting, the Uid from theoriginalUidCookie is inserted into the UidCookie in step 674. Editingthe UidCookie in step 674 thus reverts the user back to the rights andprivileges that the user originally had before the process of FIG. 15.In one embodiment, the originalUidCookie is deleted in step 674.

[0179] A lot of the tasks that are performed in the Identity System areaccomplished using workflows. A workflow is a predefined set of stepsthat perform a specific task, where information or tasks are passedbetween participants and programs according to a defined set of rules.One embodiment of the present invention supports the following types ofworkflows: create object; delete object; change the value of attributes;and certificate issuance, revocation and renewal. In one embodiment ofthe present invention, a user is required to create a workflow to createor delete an object, change the value of an attribute or implementcertificates. Workflows ensure that an organization's guidelines forperforming a task are met. Workflows can be defined in the User Manager,Group Manager or Organization Manager. A workflow can be used only inthe application (e.g. User Manager) in which it was created. Eachworkflow has two or more steps, including one to start the action andone to implement or commit it. Each step can contain an action, sende-mail notifications to selected persons and start the next step if itsentry conditions are satisfied. A workflow is associated with a portionof the directory tree. This allows an entity to have its organizationsand partners enforce different workflows. Workflows can be stored inDirectory Server 36.

[0180] Table 1 provides examples of different tasks that can beperformed with workflows in the appropriate applications: TABLE 1Application Workflow Tasks User Manager Create User Delete User ChangeAttribute Certificate Enrollment Certificate Renewal CertificateRevocation Group Manager Create Group Delete Group Change Attribute Org.Manager Create Object Delete Object Change Attribute

[0181] Each workflow includes two or more steps. Each step can includeone or more actions. Table 2, below, provides examples of differentactions that can be performed with various types of workflows: TABLE 2Workflow Type Actions Creating object Initiate Self Registration ProvideInformation Approval Provide Information and Approval Activate CommitError Report External Action Deleting object Initiate Change InformationApproval Change Approval Deactivate Commit Error Report External ActionChanging Attribute Request Approval Provide Information ProvideInformation and Approval Commit Error Report External Action

[0182] Table 3 provides a description of the various actions: TABLE 3Action Description initiate This action initiates workflows. Required,option, and supplied attributes may be configured for this action. Basedon the relevant data configured in the step, the action will compose apage for the user to fill in the required information and to addadditional attributes for provisioning (supplied variables) if sodesired. Once the page is submitted, the workflow engine will triggerthe Change Attribute workflows for the supplied attributes. People whoare configured as a participant for this action and its correspondingworkflow will see the “Create Profile” or “Initiate Deactivate User”button. self_registration This action allows an e-user to fill in aregistration form and submit it for acceptance. The required informationwill be displayed on the page. It is envisioned that self-registrationwill be used before the user has access to an application. Therefore,the UI of this page will be designed without the context of anapplication and with credentials for authentication. request This actionmakes a request for change/add/delete attribute. People who areconfigured as a participant for this action and its correspondingworkflow will see the “Request to Modify” or “Request to Remove” buttonon the profile page (during “modify” mode). provide_info This action issimilar to initiate, in that it collects information from the user andtriggers other workflows, if necessary. It is treated as a differentaction from initiate for the following reasons: Initiate is always thefirst action in the workflow. Provide_info can occur at multiple placesin a workflow while initiate can not. The people who can initiate theworkflow may be different from those who can provide intermediateinformation. Only the people configured as the participants for theinitiate action will see the “Create Profile” button. Provide_info willtry to retrieve the required attributes to display the values to theuser. This allows the information setup in the previous steps or in thedirectory to be changed. change_info This action is identical inbehavior to provide_info. A different name is used because the namechange_info makes more sense in the case of deactivating. approval Thisaction can be configured with only the required attributes. At run time,the values of the required attributes will be presented to the user toget approval. No information is supposed to be changed. The only useraction allowed is to click on the button to indicate approve or reject.In other embodiments, a digital signature could be used to provide anonrepudiation approval. Provide_info and approval This action combinesthe provide_info and the approval into one action. In some situation,customers may want the people who can approve also to be able to provideor change the information if necessary. change_approval This action isidentical in behavior to provide_approval. A different name is given toreflect the nature of the action in the deactivating context. activateThis action enables the user to explicitly mark an entry ready. Untilthis action is performed, the user's entry has been marked as“PendingActivation.” Upon completing this action, the status will bechanged to “Activated.” Once “Activated,” this user entry may be usedfor authentication to the system. deactivate This action is thecounterpart of the activate action to mark an entry suspended. Untilthis action is performed, the user's entry has been marked as “Pendingfor Deactivation.” Upon completing this action, the status will bechanged to “Deactivated.” In both of these cases, this entry will not berecognized as an authorized user in the system. commit This actionwrites the information collected this far in the previous workflow stepsto the directory. Commit can be done multiple times. The location of thewrite is the user's permanent location as selected in the “initiate”step. error_report This action is to report for a background process.When a background process encounters a processing error, it has noproper way to report the error since there is no responsible person forthe action. The workflow definer can configure the failed path to thiserror_report step, so that the error can be designated to theresponsible individuals. external_action External action can be pluggedinto the workflow as a distinct step.

[0183] Workflows are created based on templates (forms) by users withsufficient privileges. In one embodiment, each template has at leastfour sections including a section for creating objects, deletingobjects, changing attributes and working with certificates. The templateprovides parameters that define how workflows can be created. Templatescan be edited in order to tailor the workflow definition processes. TheUser Manager, Group Manager and Organization Managers each have theirown template files and use those template files to control and definethe workflow definition process. In one embodiment, the template file isan XML document that defines a set of parameters for each of the actionsavailable to that particular workflow type. Table 4 describes thevarious parameters that are used in the template files: TABLE 4Parameter Description Sample Setting occurrence Indicates how many times[1][n] this action may be used 1—action can be used within a workflow.once. n—action can be used multiple times. useraction Indicates whetheror not [true][false] the step is interactive. True—action requires userinteraction. False—this is a background step and requires no userinteraction. forceCommit Indicates whether an [true][false] implicitcommit takes True—implicit commit place for this step, even takes place.though this action is not a False—implicit commit commit. An implicitdoes not take place. commit writes all collected data to the specifictarget entry. pre_action Indicates that the current [list of actions]action can be specified if the previous step's action is in this list.exit_condition Indicates the possible [list of exit conditions] resultsfor the given action. For example: true: 1 false: 0 relevant_dataIndicates which types of [list of relevant data} relevant data can beCan be any configured for this step. combination of Background steps donot Required, Optional, or contain any relevant data. Supplied.

[0184] Below is a generic form of a template. In the left hand margin isa letter to identify each line of the template for explanation purposes:Generic Template © Oblix, Inc., 2001 a <CompoundList ListName =“[workflow type]”> b <CompoundList ListName = “[action]”> c <SimpleList>d <NameValPair ParamName=“occurrence” Value= [value] /> e <NameValPairParamName=“useraction” Value= [value] /> f <NameValPairParamName=“forceCommit” Value= [value] /> g </SimpleList> h <ValListListName= “pre_action”> i <ValListMember Value = “[action]” j . . . k</ValList> l <ValNameList ListName= “exit_condition”> m <NameValPairParamName = “true” Value=“0”/> n <NameValPair ParamName = “false”Value=“1”/> o </ValList> p <ValList ListName= “relevant_data”> q<ValListMember Value = “required”> r <ValListMember Value = “optional”>s <ValListMember Value = “supplied”> t </ValList> u </CompoundList>[more definitions of actions] v </CompoundList >

[0185] The first line labeled (a) indicates the workflow type, whichincludes creating an object, deleting an object, changing attribute orcertificates. Lines (b-u) define the parameters for one particularaction. One or more of the parameters described above are defined inlines (b-u) for one action. For example, line (d) puts a value into theoccurrence parameter, line (e) provides a value for a useraction andline (f) provides a value for forceCommit. Lines (h-k) provide thevarious pre-actions that have to occur before the particular action isperformed. Lines (l-o) provide exit conditions. While the generictemplate above shows line (b-u) for one particular action, a typicaltemplate would have parameters for many actions. One template is likelyto be used to create many workflows.

[0186]FIG. 16 is a flowchart providing an overview of the process forcreating a workflow. In step 700 a template is created and stored. Inone embodiment, the template can be created using a word processor. Instep 702, a workflow object is created. The workflow can be createdusing the User Manager 42, Group Manager 44 or Organization Manager 46.In step 704, the steps of the workflow are defined based on the templatecreated in step 700. In step 706, the workflow is stored. In step 708,the workflow is performed. Additional workflows can be created byperforming steps 702-708 because once a template is created, it can beused to create many workflows.

[0187]FIG. 17 is a flowchart describing the steps of creating atemplate. In step 730, each workflow type is added to the template file.In reference to the generic template above, line (a) of the generictemplate identified the first workflow type. It is likely that theworkflow types would include create object, delete object, changeattributes and certificates. In step 732, for each workflow type,actions are added. Code for one action is depicted above in the generictemplate. In step 734, for each action the parameters are added. In oneembodiment, one or more domains can be specified for a template or forworkflow types in the template. If domains are specified, then theassociated template or workflow types only apply to workflows createdfor the specified domain(s).

[0188]FIG. 18 provides a flowchart for creating a workflow object (step702 of FIG. 16). In step 750, the appropriate manager (User, Group,Organization) receives a selection or indication to create a workflow.In step 754, it is determined whether the user is allowed to create theworkflow. If no, the process is completed. If yes, the system identifiesthe different types of workflows, objects, tasks and target domains forwhich the user can create a workflow (step 756). In step 758, the userselects the identification of the workflow to be created. Theidentification is just a unique name to identify the workflow. In step760, the user inputs a selection of the type of workflow based on theoptions from step 756. Step 760 includes choosing the task that theworkflow will perform. For example, in the User Manager, the possibletasks include create a user, delete a user, change attribute, etc., asdiscussed above.

[0189] In step 762, the user specifies the domain in the directory toassociate with the workflow. In one embodiment, specifying a domainlimits the workflow to only operate on target identity profiles that arein the domain. In one implementation, the domain is specified byidentifying a node in the directory. The domain includes the identifiednode and all nodes in the tree that are below the identified node. Forexample, if a user selects node 242 of FIG. 5, then the domain includesnodes 242, 262 and 264. In one embodiment, a filter can be used so thatthe workflow can be associated with a portion of a flat tree orhierarchical tree. The filter can be an LDAP filter or other type offilter for identifying a set of entities.

[0190]FIG. 19 is a flowchart describing the process of defining stepsfor a workflow being created. The process of FIG. 19 is performed basedon the template. In step 780, the system determines the possible actionsthat can be performed for this particular workflow based on thetemplate. That is, the system reads the template and determines whichactions can be added. The actions that can be selected are added to aGUI in step 782 and, in step 784, a selection from the GUI is made bythe user. In step 786, the system determines which types (required,optional, supplied) of attributes are available, based on the template.The appropriate attributes and types of attributes are added to the GUIin step 788. For example, the various attributes can be selected asrequired, optional or supplied. If the template does not allow for thesupplied attribute, then that option will not be available on the GUI.

[0191] In step 790, the system receives a selection of the attributesand the types from the user. That is, the user will select whichattributes are optional, which attributes are required and whichattributes are supplied. An attribute is supplied if it is provided fromanother workflow. In other embodiments, other types can be used. In step792, the participants who can perform the current step being defined areidentified. They can be identified by naming them individually, naming agroup, or using an LDAP filter. In step 794, pre and post notificationsare specified. A pre-notification means that prior to the step beingperformed the following set of users are sent an e-mail (or other formof communication). Post notification means that after the step has beingcompleted the following individuals are sent an e-mail (or other form ofcommunication).

[0192] If there is another step in the workflow (step 796), then themethod loops to step 798; otherwise, the process of FIG. 19 iscompleted. In step 798 the possible entry conditions are determined fromthe template. In step 800, these entry conditions are added to the GUI.In step 802, a selection of the entry conditions is made from the GUI.In step 804, the system determines if the previous step has a subflow.If so, the user has an opportunity to indicate whether to prevent theinitiation of the current step until the subflow is completed.Determination of whether there is a subflow can be based on the templateor based on the types of data in the previous step (e.g. is theresupplied data). If there is a subflow (or multiple subflows), thenindication of the subflow(s) is added to the GUI in step 806. In step808, the system receives an indication from the GUI whether the currentstep should wait for the previous step's subflow(s) to complete. Thisindication to wait for subflows is stored as a flag with the data forthe workflow. After step 808, the method continues at step 780.

[0193] In one alternative, each subflow (for a step that had multiplesubflows) can be associated with a separate entry condition. In such anembodiment, the user can individually select whether to wait for eachsubflow.

[0194] A subflow is a workflow that is initiated by another workflow.The concept of subflow was introduced and implemented to reduceadministrative work. If a workflow already exists to perform a task, anyother workflow that needs to perform that task should be able toleverage off the first workflow. When creating a workflow, an indicationthat there is a sub-workflow is provided by the creator of the workflowwhen the creator indicates that one or more of the variables aresupplied.

[0195] The workflow that initiates the subflow is referred to as theparent workflow. A workflow can be both a parent workflow to a firstworkflow and a subflow to a second workflow. The parent workflow may ormay not wait for the subflow, as defined in the workflow creation.Consider the following example, a company uses a first workflow tocreate new users for the Identity System and add the new user's identityprofile to the directory. As part of its process, the new user workflowobtains the new user's telephone number. The obtaining of the new user'stelephone number is accomplished by performing a new telephone numberworkflow. In this example, the new telephone number workflow isinitiated by a step in the new user workflow. Therefore, the newtelephone number workflow is a subflow of the new user workflow. In onealternative, the new telephone number workflow can also call a subflow,for example, to get a new telephone line connected and operational.This, second subflow can also call a subflow, and so on. There can bemany levels of nesting of subflows. Additionally, a parent workflow canhave many subflows.

[0196] In one embodiment, a parent workflow and its subflows must all beperformed by the same application. For example, the all must beperformed by the User Manager. Or, they must be performed by the GroupManager, etc.

[0197]FIG. 20 is a flowchart describing the process of using a workflow.The process of FIG. 20 is performed, for example, when creating a newuser, a new group, etc. In step 840, the relevant manager (e.g. user,group or organization) receives a request to perform an action thatrequires a workflow. Most actions are likely to have an effect on atleast one identity profile in the directory. In step 842, it isdetermined whether this user is allowed to initiate the workflow. Ifnot, the process of FIG. 20 is completed. If so, the GUI determines andreports a set of one or more workflows. This set of one or moreworkflows meets three criteria: (1) the user is allowed to use theworkflows, (2) the workflows perform the requested task and (3) theworkflows are associated with a domain that includes the target of thetask. For example, if user A has requested to modify the attributes ofEmployee 8 (identity profile 264 of FIG. 5), then the system willidentify and report workflows that (1) user A has permission to access,(2) perform attribute modification and (3) are associated with a domainthat includes identity profile 264 of FIG. 5. In one embodiment, theidentified workflows are displayed in a menu.

[0198] In some situations, a workflow is requested without knowing thelocation of the target identity profile. For example, a user can requestto create an object without indicating where to store the object in thedirectory. In such a scenario, the system will find and report workflowsthat perform the requested task and can be accessed by the user. Whenthe system reports the list of workflows (e.g. via a GUI), the systemwill also report the domain associated with each workflow. In thissituation, step 846 includes the system receiving a selection from theuser of the workflow desired, and the domain to operate on.

[0199] In step 846, the system receives a selection from the user of thework flow desired. Note that is step 844 only identified one workflow,then step 846 can be skipped or performed automatically. In step 850, itis determined whether the user is allowed to perform this workflow step.If not, the process of FIG. 20 is completed, at least temporarily. Oneembodiment of the process of FIG. 20 does not include step 850. If theuser is allowed to perform the step, then the event catalog is accessedin step 852. The event catalog, which will be discussed in more detailbelow, is a list of events that trigger actions (e.g. cross applicationworkflows) external to the workflow. In one embodiment, the eventcatalog is only checked if the template allowed for the use of externalactions. For example, one of the actions allowed in a workflow step anddefined in a template is “external_action.”

[0200] In step 854, pre-notifications, if any, defined in the workfloware sent out. In step 856, cross application workflows, if any, areinvoked, as per the event catalog. In step 858, the current step of theworkflow is performed. In step 860, it is determined whether there aresupplied variables. When creating a workflow, the creator had the optionof defining the types of variables. Supplied variables are thosevariables whose value will be supplied by a subflow. If the current stephas a supplied variables, then the system searches for any workflowsthat can supply the variable and apply to the appropriate domain. Ifonly one workflow is found for each supplied variable, then thoseworkflows are initiated as a subflow in step 862. If multiple workflowsare found for a particular supplied variable, then the user is given achoice and the chosen workflow is initiated as a subflow in step 862.Note that the subflow could itself have a subflow, which could itselfhave a subflow, and so on. There is no limitation on the number ofsubflow nestings.

[0201] If there are no supplied variables, or after the subflow(s) arestarted, the event catalog is accessed in step 864. Note that crossapplication workflows can be started pre-step or post-step. Step 864 isfor post-step cross application workflows. In step 866, post stepnotifications are sent out, if any. In step 868, the next step isaccessed from the workflow definition. If there are no more steps, thenthe process of FIG. 20 is completed. In step 870, the event catalog ischecked. In step 872, pre-notifications are sent out.

[0202] In step 874, the system determines whether the user is allowed toperform the next step. If not, the process of FIG. 20 is stopped. If so,the system determines in step 876 whether it has to wait for thesubflow(s) started in the previous workflow step. In one embodiment, aflag is set at workflow creation time to indicate that the workflowshould wait or not wait. If there is a subflow and the current workflowhas to wait, the system continues to wait until the subflow iscompleted. If there is no subflow or it does not have to wait, then thesystem determines whether all entry conditions have been satisfied instep 878. If not, the system waits for the entry conditions to besatisfied. If yes, the process continues to step 856.

[0203] Note that different steps may be set up for performance bydifferent users. Thus, a first user may start the workflow but adifferent user or a different set of users may be needed forintermediate steps. Therefore, the process of FIG. 20 performed by theinitial user may temporarily halt. As described above, if another useris needed to perform a step, that user will be notified either by e-mailor through one of the request tabs discussed above. When that userdesires to perform the step, the user will request access to theworkflow in step 884 of FIG. 20. For example, the user can respond to alink in an e-mail or select a workflow listed in one of the requesttabs. In step 886, the step for that particular user is accessed, andthen the method continues with step 874 of FIG. 20.

[0204]FIG. 21 is a flowchart describing the process for using a subflow.In step 900, the workflow engine (part of Identity Server 40) receivesan indication that a variable/attribute is to be supplied. In step 902,the engine determines whether a workflow exists for that particularvariable that applies to the user and domain. If not, the process isdone and the supplied variable is not supplied. If there is a workflowavailable, then that workflow is performed in step 904. When theworkflow is completed, it is determined whether the main workflow(parent workflow) is still active. The parent workflow may still beactive because it is waiting for the subflow to complete. Alternatively,if the parent workflow is not waiting for the subflow to complete, thenthe parent workflow may not necessarily be active. The parent workflowmay be completed.

[0205] If the parent workflow is still active, then the result of thesubflow is written to the parent workflow in step 908. If the parentworkflow is not active, then the result is written to the targetidentity profile in step 910. In an alternative embodiment, the endresult of the subflow can be written to the target identity profileregardless of whether the parent workflow is still active or not. Notethat a subflow may have a subflow of its own, which would cause theprocess of FIG. 21 to operate in a recursive manner. There is no limiton the number of subflow nestings.

[0206] A workflow is performed by one of the three managers describedabove (User Manager, Group Manager, Organization Manager). There may becases when one workflow in one of the applications (e.g. user manger)needs to trigger a workflow in another application (e.g. Group Manager).For example, when creating a new user with a workflow in the UserManager, it may be beneficial for that workflow to trigger anotherworkflow in the Group Manager which subscribes the new user to groups. Across application workflow is performed using the event catalogdescribed above, a client program and (optionally) a configuration filefor the client program, all of which will be described below.

[0207] The cross application workflow uses a pre and post processingfeature of the integrated Identity System and Access System. The pre andpost processing allows third parties to extend the base of functionalityof the system by providing custom actions based on specific definedevents. The base elements of pre and post processing are called events.Events occur any time the user interacts with the system. Events can beas simple as adding, modifying or deleting an object or could be ascomplex as a specific step within a workflow process.

[0208] Actions are functions or applications that perform a task inresponse to an event. These actions are defined to enhance the basefunctionality of the system of FIG. 1. Multiple actions can be definedfor each event. Actions are executed in the order that they appear in anevent catalog. Actions are defined using a plug-in model similar to WebServer CGI model. Functions are applications defined for each customaction. Each function/application will take a standard XML structure asits parameters that allow the system to specify information about theevent that triggered the function. Action functions are defined withinlibraries (.dll or so) or stand alone executable files. To create a newaction based on an event, one must insert a hook into the event catalog.All entries in the event catalog are defined in the following format:

[0209] actionName; exectype; param1, param2, . . . ; path; execparam;func;

[0210] The “actionname” is the name of the event. The convention formost events is APPNAME_(—EVENTNAME)_PPPTYPE, where APPNAME is the nameof the application, EVENTNAME is the name of the event and PPPTYPE isthe type of processing (pre event or post event). For a workflow, theAPPNAME is the workflow ID for the workflow, the EVENTNAME is the stepnumber in the workflow. The “exectype” is a type of hook, which can beexec or lib. An exec is an executable. A type that is lib is in alibrary such as a dll. The “param” is the parameter, which the systemtakes to output the value. The parameters are deliminated by commas. The“path” is the path for the external exc or dll to be launched. The“execparam” identifies the input parameters, deliminated by a comma. The“func” is the function in the shared library. Thus, when the eventdefined in actionName occurs, the appropriate executable or libraryfunction is called.

[0211] The function in the shared library or the executable that is tobe executed upon the event (hereinafter referred to as the “clientprogram”) needs to include logic to decide which workflow (or otherprocess) to be invoked. It can make use of a configuration file to havea mapping between workflows and any distinguished names, values ofattributes, system parameters and any other variables of interest. Thisclient program, after deciding which workflow to call, must connect tothe system. In some embodiments, the client program does not call anyworkflows—rather the client program does all of the work or the clientprogram calls another program/function.

[0212] In one embodiment, the integrated Access and Identity Systemaccepts XML document inputs that are encapsulated in a SOAP envelopeusing HTTP protocol requests. The XML document contains the necessaryparameters and authentication information for carrying out the request.The request is sent to an appropriate URL for the desired application.The Identity System provides the desired application's response to theclient program as an output XML document.

[0213] The XML input language is a language based on SOAP that allowscustomers to perform functions outside of the current GUI. The structureof SOAP requests is explained in greater detail below.

[0214] One example of a use for a cross application workflow is for anew user workflow to spawn a subscribe to group workflow. The followingis the XML input to spawn the subscribe to group workflow: © Oblix,Inc., 2001 <?xml version=“1.0”?> <oblix:requests> <authenticationtype=“basic” login=“newuser” password=“passwd”> <oblix:requestapplication=“groupservcenter” function=“SetGroupSubscription”includeRequest=“none” displayOutput=“No”> <oblix:params> <oblix:paramname=“useruid”> <oblix:value>cn=new user,ou=engineering,o=company,c=us</oblix:value> </oblix:param> <oblix:paramname=“groupuid”> <oblix:value>cn=engineering group,ou=engineering,o=company, c=us</oblix:value> </oblix:param></oblix:params> </oblix:request> </oblix:requests>

[0215]FIG. 22 is a flowchart describing the process for creating a crossapplication workflow situation. In step 940, the first workflow for thefirst application is created. For example, the create user workflow forthe User Manager application is created. In step 942, the secondworkflow for the second application is created. For example, thesubscribe user to group workflow can be created in the Group Managerapplication. In step 944, an entry is added to the event catalog. Forexample, an entry is added to the event catalog that indicates theworkflow ID for the workflow created in step 940—the step that shouldspawn the second workflow and that it is a post event. The entry alsoidentifies the client program that will be created (see below). In step946, the client program is created which invokes the second workflow.This client program receives the distinguished name of the newly createduser as a parameter. In another embodiment, the client program receivesother attributes from the identity profile being operated in by originalworkflow. The client also receives the workflow instance, the work stepidentification, and attributes of the work step. In step 948, aconfiguration file may be created for the client program. For example,if the second workflow is to subscribe a user to a group, then theconfiguration file may include rules for which users should be added towhich groups.

[0216]FIG. 23 is a flowchart describing the process of accessing theevent catalog in order to invoke cross application workflows. Theprocess of FIG. 23 is performed by a workflow engine in one of theapplications during steps 852, 864 and 870 of FIG. 20. In step 978 ofFIG. 23, the workflow engine determines whether there is an entry in theevent catalog for the current step of the workflow. If step 856 is beingperformed, the workflow engine is looking for a catalog entry that is apre-event. If step 860 is being performed, the workflow engine islooking for a catalog entry that is a post-event. If no catalog entriesexist, then the process of FIG. 23 is done. If a catalog entry exists,then the client program identified in the catalog entry is invoked instep 980. In step 982, the parameters are passed to the client program.In step 984, the workflow engine waits for a response from the clientprogram. The client program will respond with one of three status codes:success, fail, or async. If the return code is “success” then the crossapplication workflow did not cause the step to fail (step 998). If theresponse from the client program was “fail” then the workflow engineconsiders the step to have failed (step 990).

[0217] When the client program is called, it is passed the followinginformation: distinguished name of the user, attributes that have beenpreconfigured in the event catalog, a callback handle URL and theworkflow ID. The callback handle URL is a URL for the client program tocall back the workflow if the workflow returns a “async” status code.The client program is written to return either failure, success or asyncdepending on the conditions specific to that particular program. Whenthe client program returns with “fail” or “success” the workflowcontinues. If the client program returns “async,” then the firstworkflow pauses until the client program invokes the callback handle URLto start the first workflow again. When the client program sends an“async” status, the user at the browser receives a status message thatthe workflow is pending for another event.

[0218] Therefore, in step 986, if the response is “async” then theworkflow engine pauses and waits for the client to return in step 992.The user is provided with a message that the workflow is paused. Whenthe client program invokes the callback URL (step 994), the workflowengine will receive an asynchronous response of either a “success” or“fail” with the callback URL. If the result is “fail” (step 986), thenthe process continues at step 990. If the result is “success” (step986), then the process continues at step 988.

[0219]FIG. 24 is a flowchart describing a process performed by theclient program during the cross application workflow process. In step1010, the client program is invoked. In one instance, the client programis invoked in response to an event being recognized in the eventcatalog. For example, step 1010 can be performed in response to step 980of FIG. 23. In step 1012, the client program receives the data discussedabove (see step 982 of FIG. 23). In step 1014, the client program readsthe configuration file. Note that some client programs may not need aconfiguration file.

[0220] In step 1016, the logic in the client program determines whichworkflow in which application to invoke. In step 1018, the clientprogram composes a request in an XML document, as described above. Instep 1020, the client program connects to the appropriate applicationusing SOAP. In step 1022, the XML input document is sent to the relevantapplication. In response to the XML input document, the application willperform the requested workflow or other service. In step 1024, theapplication responds, and the client receives an indication of whetherthe second workflow was started successfully.

[0221] In step 1026, the client program returns a status message back tothe workflow engine indicating success, failure or async, based onwhether the second workflow started successfully and other custom logic(optional). In step 1028, the client program waits for the outputmessage from the application running the second workflow. The outputmessage is likely to be sent to the client program after the secondworkflow is completed. The output message is an XML document. In step1030, the output message is processed (including being read and actedon). In step 1032, the client program invokes the callback URL if theprevious status was “async.” Note that the above discussion was tailoredto cross application workflows. However, the pre and post processingfeatures, including the event catalog, client program and XML inputs,can be used to associate with events other than workflow events andother than workflow actions.

[0222] Looking back at FIG. 9, one of the services provided by GroupManager 44 is to the ability to view a list of all groups of which auser is a member. A user can be a static member of a group, a dynamicmember of a group or a nested member of a group. A user is a staticmember if the user is explicitly listed as a member. For example, theuser can be identified in a membership attribute of the group identityprofile. A user is a dynamic member if the user's identity profilematches the LDAP rule that specifies the group's dynamic membership. TheLDAP rule is stored in an attribute of the group identity profile. Auser is a nested member of Group A if the user is a member for Group Band Group B is a member of Group A. The number of levels of nesting isnot limited. A nested member of a group receives the privileges of beinga member, including receiving access to resource available to the group.

[0223] When a user selects the My Groups tab 434, the user is providedwith a list of the groups for which the user is a static member, dynamicmember or nested member. In one embodiment, My Groups tab 434 visualizesthe containment relationship of all groups in which the user is amember. This relationship is displayed as a tree on its side, with theroots on the left and the leaves on the right. The display allows theuser to tunnel down from a particular group to display the groupscontained in (e.g. that are a member of) that group, and so on. FIG. 25is a flowchart describing one embodiment of a process for determiningall the groups of which a user is a member, including static membership,dynamic membership and nested membership. The process can be used tobuild a tree structure in which the nodes are groups that contain theuser as a member. The leaf nodes of the tree are those groups in whichthe user is a static or dynamic member. All other nodes are groups inwhich the user is a nested member. The process of FIG. 25 assumes thefollowing:

[0224] Let u denote the target user;

[0225] Let g denote a single group;

[0226] Let G denote a set of groups, where the g_(i) denotes the i^(th)group in the set;

[0227] Let G_(s) denote the set of groups in which u is a static member;

[0228] Let G_(d) denote the set of groups in which u is a dynamicmember; and

[0229] Let G_(t) denote the set of groups in which each g_(i) has areference to each of its containing groups.

[0230] The process of FIG. 25 starts at step 1100 when a user requeststo view groups of which the user is a member. One example of performingstep 1110 is the selection of My Groups tab 434 (see FIG. 9). In step1102, the system determines all groups of which the user is a staticmember. Each group identity profile has an attribute defining staticmembership. The system determines all groups for which the user isspecifically listed in the static membership attribute. In step 1104,the system determines all groups of which the user is a dynamic member.A group can have an attribute that defines a dynamic membership in termsof an LDAP filter/rule. In one embodiment, the system compares theuser's identity profile with the LDAP filter for each group to determinewhich filters are satisfied by the user's identity profile. Those LDAPfilters that are satisfied are groups in which the user is a dynamicmember.

[0231] In step 1106, the set of groups that the user is a static memberof and the set of groups that the user is a dynamic member of arecombined to determine the set of groups in which the user is either adynamic or static member. In step 1108, the final set of groups G_(t) isinitialized to the set of groups in which the user is either a staticmember or dynamic member. For each group in which the user is a staticor dynamic member, the system calls the function Find_Containing_Groups(step 1110). The results of the function are added to the set G_(t). Instep 1114, the resulting set G_(t) is reported as an identification ofall the groups in which the user is either a static, dynamic or nestedmember. The resulting set can be reported in various ways includingreporting the groups in a GUI for the user (e.g. a tree on its side),reporting the groups to the user in a non-graphical format, storing alist of the groups in a file, providing identifications of the groups toanother process, etc. In one example, the access system requests thatthe Identity System determine a user's groups so that the access systemcan authorize a user to access a resource based on membership in aparticular group.

[0232] The function Find_Containing_Groups (shown as step 1112) includesthree sub-steps. In the first sub-step (substep 1 in step 1112), thesystem finds all groups that contain g_(j) as a member. These are thecontaining groups of g_(j). In the second sub-step, the system iteratesover the set of containing groups. In sub-step 2.i. (step 1112), thesystem marks g_(i) as a containing group g_(j). The markings areprovided in order to graphically show the nesting relationship in MyGroups tab 434. In sub-step 2.ii. (step 1112), the system recursivelyfinds the containing groups of g_(i). In sub-step 3 (step 1112), thesystem returns the closure of the set of containing groups.

[0233]FIG. 26 is a second embodiment of a process for determining thegroups in which the user is a member. The process of FIG. 26 is a moreoptimized method than FIG. 25. The process of FIG. 26 utilizes thefollowing assumptions:

[0234] Let u denote the target user;

[0235] Let g denote a single group;

[0236] Let G denote a set of groups where g_(i) denotes the i^(th) groupin the set;

[0237] Let G_(s) denote the set of groups in which u is a static member;

[0238] Let G_(d) denote the set of groups in which u is a dynamicmember;

[0239] Let G_(ni) denote the set of groups in which u is a nestedmember, where i denotes the i^(th) level of nesting;

[0240] Let G_(n) denote the set of G_(ni) where i is the i^(th) set ofgroups;

[0241] Let G_(c) be a set of groups, where g_(j) denotes the j^(th)group in the set; and

[0242] Let G_(m) be a set of groups, where g_(k) denotes the k^(th)group in the set, such that for all g_(k), there exists g_(j) such thatg_(k) is a static member of g_(j).

[0243] In step 1140 of FIG. 26, the system receives a request to viewgroups of which a user is a member. One example of performing step 1140is the user selecting My Groups tab 434. In step 1142, the systemdetermines the set of groups G_(s) in which the user is a static member.In step 1144, the system determines the set of groups G_(d) in which theuser is a dynamic member. In step 1146, the variable i is initialized tonesting level 0. In step 1148, G_(ni) is initialized to be the union ofG_(s) and G_(d). In step 1150, the system iterates until the set ofgroups for the i^(th) level of nesting is empty, finding the (i+1^(th))set of groups which contain groups that have a static member that is inthe i^(th) set of groups.

[0244] In step 1152, the system iterates over the set of groups inG_(n). In step a, G_(c) is set to G_(ni+1). In step b, G_(m) is assignedto equal G_(ni). In step c, the system iterates over the containing setof groups G_(c). In step d, the system iterates over the contained setof groups G_(m). In step e, the system determines if group g_(k) (thecontained group under consideration) is a static member of the groupg_(j) (the containing group under consideration). In step f, thecontaining group g_(j) is marked as a containing group of g_(k), ifg_(k) is a static member of g_(j). In step 1154, the system iteratesover the set of G_(ni), adding each set of groups to the final setG_(t). In step 1156, the resulting set of groups G_(t) is reported backto the requester.

[0245] Another feature of the Group Manager is to allow a user to viewall the members of a group. For example, when a list of groups ispresented in response to a search or a request to “view all my groups,”a user can select a group and request to see all the members. A responseto this request from Group Manager 44 will list all static members,dynamic members and nested members of the group. In one embodiment, eachtype of membership (static, dynamic, nested) is displayed as separatelists. In other embodiments, one combined list is displayed. To displaystatic and dynamic membership of the group is somewhat straightforward.Static membership is stored directly in the group's identity profile. Adynamic membership is obtained by evaluating the LDAP rule/filter thatspecifies the group's dynamic membership. However, the nested membershipis more difficult to determine, since the membership of nested membersmust be recursively calculated.

[0246]FIG. 27 is a flowchart describing one embodiment of a process fordetermining all members of a group, including static members, dynamicmembers and nested members. The process of FIG. 27 assumes thefollowing:

[0247] Let U_(t) be the total set of group members including static,dynamic and nested;

[0248] Let g denote a single group;

[0249] Let G denote a set of groups;

[0250] Let g, denote the i^(th) group in G;

[0251] Let U_(s) (g) denote the set of static user members of group g;

[0252] Let G_(s) (g) denote the set of static members of group g;

[0253] Let U_(d) (g) denote the set of dynamic user members of group g;and

[0254] Let g_(t) be the target group.

[0255] In step 1200, the system receives a request to view the membersof a group. In response to the request, the system calls the functionGetMembersOfGroup in step 1202. The result of the functionGetMembersOfGroup is a set of users U_(t), which is reported in step1204. The function GetMembersOfGroup includes three steps. In the firststep (1), the static members of group g are added to the total setU_(t). In the second step (2), the dynamic members of group g are addedto the total set U_(t). In the third step (3), the system iterates overthe set of static group members of group g—adding the members for g_(i)to the total set U_(t) by recursively calling the functionGetMembersOfGroup.

[0256]FIG. 28 is a flowchart describing a second embodiment for theprocess of determining the members of a group. The process of FIG. 28assumes the following:

[0257] Let R denote a set of LDAP rules;

[0258] Let r denote an LDAP rule comprised of three components: r_(sb),scope r_(c) and filter r_(f);

[0259] Let r₁ denote the i^(th) rule in the set R;

[0260] Let g_(r) denote the LDAP rule that specifies the dynamicmembership of the group; and

[0261] Let R_(n) denote the normalized set of LDAP rules, there does notexist r_(i) and r_(j) such that r_(1-sb)=r_(j-sb) and r_(1-c)=r_(j-c).

[0262] In step 1220 of FIG. 28, the system receives a request to viewmembers of a particular group. In step 1222, the functionGetMembersOfGroup is called. This function includes three steps. In thefirst step (a), the static members of group g are added to the totalmember set U_(t). In the second step (b), the dynamic membership ruleg_(r) is added to R. In the third step (c), the system iterates over theset of static group members of g, G_(s) (g), calling GetMembersOfGroupfor each g_(i) and G_(s) (g). The function GetMembersOfGroup adds allstatic members of g to the total member set U_(t), and adds the LDAPrule specifying dynamic membership of g to set R.

[0263] In step 1224, the system iterates over the set of rules R,constructing the normalized set of rules, R_(n). In substep (i) of step1224, the system initializes the match to false, and j to 0 for eachiteration. In substep (ii), the system iterates over the set of rules inthe normalized set R_(n), continuing until a match is found or until theend of the set. The system checks if the rule r_(i) in R has identicalsearch base (rsb) and scope (r_(s)) as the rule r_(n,j), in thenormalized set R_(n). If so, the system constructs the disjunction ofthe filter in the normalized rule r_(nj) with that of r_(i). The systemalso sets match to true to indicate that r_(i) has been normalized. Insubstep (iii) of step 1224, if a rule r_(nj) has not been found in thenormalized set R_(n) that has an identical search base (r_(sb)) andscope (r_(s)) as r_(i), then add r_(j) to the normalized set. In step1226, the system iterates over the set of normalized rules in R_(n),getting the user set for each rule U (rii) and adding that set to thetotal member set U_(t). In step 1228, the total member set U_(t) isreported back as a list of members. Once you have identified a list ofmembers, a requesting entity can request to view certain attributes ofthose users.

[0264] Group manager 44 also allows an administrator to associate apolicy with a group that controls user subscription to andunsubscription from that group. Subscription is defined as adding theuser to the static membership of the group. Unsubscription meansremoving the user from the static membership of the group. A staticmember is a member who is explicitly identified as a member, as opposedto a dynamic member that is indirectly identified by a rule or othermeans. In one embodiment, an identity profile for a group includes anattribute that stores a list of all static members and an attribute thatstores an identification of the policy for subscribing/unsubscribing.

[0265] While viewing the attributes of a group, a user can request tosubscribe or unsubscribe. In one embodiment, a “subscribe” button or“unsubscribe” will be displayed in the GUI while the user views theattributes of a group. By selecting the button, the subscribe orunsubscribe process will start based on the policy for that group. Theprocess of subscribing or unsubscribing according to a policy istypically initiated by the user who is being added to or removed fromthe group. However, in other embodiments, a first user can request thata different user be added to or removed from the group.

[0266] There are at least four policies for subscribing/unsubscribing:open, open with filter, control through workflow and closed. An openpolicy does not restrict subscription or unsubscription, any user cansubscribe or unsubscribe. The open with filter policy requires that auser satisfy an LDAP rule (or other type of rule) to subscribe but doesnot require that the rule be satisfied to unsubscribe. The controlthrough workflow policy requires a user to subscribe or unsubscribethrough a workflow process. In one embodiment, in order to start theprocess, the user must be a participant in the first step of a workflowthat changes the static member attribute of the group. A closed policyprohibits the subscription to or unsubscription from the group. The openand open with filter policies are less restrictive than the controlthrough workflow and close policies. In one embodiment, the systemenforces the rule that no group with a less restrictive policy can beadded as a nested member to a group with a more restrictive policy. Thisrule avoids subversion of the latter policy.

[0267]FIG. 29 is a flowchart describing the process for subscribing to agroup. While interacting with Group Manager 44, a user can use searchtool 432 or other means to identify a list of groups. By selecting oneof those groups, the user can access the profile page for that group(step 1250). A profile page may have a “subscribe” button. A userchooses the “subscribe” button in step 1252, indicating that the userwishes to subscribe to that group. In response to the user (or otherentity) selecting the “subscribe” button, Group Manager 44 accesses thegroup's attribute that stores the identification of the policy forsubscribing/unsubscribing and determines whether the subscription policyof the group is “open” (in step 1254). If the policy is “open,” thenthat entity is added to the group in step 1256. If the policy is notopen, then the system determines whether the policy is “open withfilter” (in step 1258). If so, the system accesses the LDAP ruleassociated with the policy in step 1260 and applies the LDAP rule to theuser's identity profile in step 1262. If the LDAP rule is satisfied(step 1264) then the entity is added to the group in step 1266. If therule is not satisfied, then the user is not added to the group and thesubscription fails in step 1268.

[0268] If the subscription policy was not open or open with filter, thesystem determines whether the subscription from policy is “controlledthrough workflow” (step 1270). If so, then the workflow is initiated instep 1274. If the workflow completes successfully (step 1276), then theentity is added to the group in step 1278; otherwise, the subscriptionfails and the entity is not added to the group in step 1268. In oneembodiment, the workflow is used to approve a user for a group. If theuser is approved, the user is added to the group after the workflowcompletes. In another embodiment, the user is approved and added to thegroup by the workflow. If the subscription policy is not “open,” “openwith filter,” or “controlled through workflow,” then the group is closedand the user cannot be added to the group (step 1272).

[0269]FIG. 30 is a flowchart describing the process for unsubscribingfrom a group. In step 1300, the entity accesses a group profile page.This group profile page may include a “unsubscribe” button. The userselects that button to unsubscribe from the group in step 1302. The userprofile page may be accessed in many ways including using a search toolor from a list of groups when the user selects My Groups tab 434. Afterthe user selects to be unsubscribed from the group, the systemdetermines whether the subscription policy is “open” or “open withfilter” (step 1304). If so, the entity is removed from the group in step1306. If not, the system determines whether the policy is “controlledthrough workflow” (step 1308). If not then the group is closed and theentity cannot be removed (step 1310). If it is “controlled throughworkflow,” then the workflow is initiated to step 1312. If the workflowcompletes successfully (step 1314), then the entity is removed from thegroup in step 1316. If the workflow does not complete successfully, thenthe entity is not removed from the group (step 1318). In one embodiment,the user is approved for removal by the workflows, and actually removedfrom the group after the workflow completes. In another embodiment, theuser is both approved and removed from the group by the workflows.

[0270] Another feature of Group Manager 44 is the ability to performgroup expansion. Expanding a group means evaluating the LDAP rule thatspecifies its dynamic membership and then updating the static membershiplist with results of the evaluation of the LDAP rules. Expansion, ineffect, populates the static membership with a snapshot of the dynamicmembership at the time of expansion. Expansion has performanceimplications. On one hand, it is much faster to evaluate groupmembership by looking up a value in the static membership list than toevaluate the rule that specifies dynamic membership. On the other hand,frequently updating groups is, in itself, computationally expensive. Ifthe expansion occurs as a separate process, the performance hit can behidden from the user. Thus, if a group is already expanded when a userrequests to see all the members of a group, the processes of FIG. 27 or28 do not need to be performed again because the group only has staticmembers at this point. An administrator should expand the groupsregularly to maintain accuracy. It may be possible to create abackground process that automatically expands a group at certainintervals.

[0271] In one embodiment, the group expansion feature can be accessedfrom Configure tab 440 in Group Manager 44. Within the configure tabthere is a button labeled “Expand Dynamic Groups.” FIG. 31 is aflowchart for describing the process for expanding dynamic groups. Whenthe user selects the button in Configure tab 440, a request to expand issent to Group Manager 44 in step 1350. The administrator can select aparticular group or set of groups to be expanded in step 1352. In step1354, these groups are expanded by determining all of the members of thegroups according to the processes of FIGS. 27 or 28. In one embodiment,the process of expanding the groups only determines dynamic members. Inanother embodiment, the process of expanding determines dynamic membersand nested members (including multiple levels of nesting). Step 1354also includes storing all of the determined members. In one embodiment,the system will store and keep track of which group members were addedduring expansion and which members were original static members. That isbecause future expansions may remove some members that no longer satisfythe LDAP rule; however, members who are named static members will not beremoved as part of the expansion process.

[0272] When an entity accesses the groups that were expanded in step1354 and/or requests to see the members of the group (step 1356), theentity sees the expanded list of members. Additionally, any process thatneeds to access members of a group will access the membership generatedin the expansion process. In one embodiment, the process of FIG. 31 canbe automatically repeated (step 1358) using a background process or anyother means.

[0273] In one embodiment, the process of expanding groups can only beperformed on groups that have an expansion attribute that is set totrue. Additionally, the person or entity expanding the group must haveread access for the group expansion attribute and the dynamic filterattribute. That user must also have write access for the static memberattribute. In one embodiment, all the expanded members are stored in thestatic member attribute with the original static members. In anotherembodiment, all of the original static members can be stored in oneattribute and the members added during expansion stored in anotherattribute.

[0274] Another feature of Group Manager 44 is the ability to dynamicallymodify groups during run time. This feature is based on attachingauxiliary object classes to structural object classes. A structuralobject class can be instantiated to create a group such that for eachentry in the directory there is only one structural object class. Thestructural object class cannot change after the object has beeninstantiated and is being used. One or more auxiliary object classes canbe attached to any structural object class in a directory. Thestructural object class defines a set of attributes. The auxiliaryobject class also has a set of attributes. When an auxiliary objectclass is attached to an object class, the attributes of the auxiliaryclass are added to the object. Once instantiated, a structural objectclass cannot be modified or removed; auxiliary object classes, however,can be added or removed. Group manager 44 provides the user with theability to add or remove auxiliary object classes on the fly using aGUI.

[0275] Prior identity systems allow for the addition of auxiliaryclasses to structural classes upon creation of the object. The presentinvention allows for auxiliary classes to be added and removedsubsequent to object creation. That is, dynamically, an existing objectclass can have additional attributes added to the group object orremoved from the group object by adding or removing auxiliary classes.

[0276] When creating a group, an administrator (or other user withsufficient privileges) is provided with a graphical user interface thatlists all possible attributes that can be included in the group profile.Some of these attributes are part of structural object class, whileothers are part of auxiliary object classes (or auxiliary object classschema). If the user selects attributes from an auxiliary class, thenthose auxiliary classes are added to the object upon creation of theobject. After the group is created, various attributes can be populatedwith data values. Subsequent to this time, attributes that areassociated with auxiliary classes can be removed or added to the group.In addition to adding flexibility to defining which attributes areassociated with a group, the present invention allows for bulk deletionof attributes. Simply removing the auxiliary object class from the groupentry will automatically delete all attributes of the removed auxiliaryobject class.

[0277]FIG. 32 is a flowchart describing an overview of the process foradding and removing attributes to a group during run time. In step 1398,a group is created. This step includes determining which attributes toinclude in the group definition. Based on the attributes chosen, astructural class and the appropriate auxiliary classes are added to thegroup. In one implementation, the group is created by instantiating theappropriate classes to create a group object representing the groupidentity profile. In one embodiment, a group can be created that has anauxiliary class, but no attributes of that auxiliary class. The systemcan use a workflow to create the group and the workflow knows whichauxiliary classes to use. The arrow from step 1398 to step 1400 isdepicted as a doted line to indicate that time and other steps passbefore step 1400 is performed. That is, step 1400 is performed after agroup has been created and, possibly, after the various attributes havebeen populated with data. In step 1400, Group Manager 44 receives arequest to modify the existing group. This can happen from Configure tab440. Alternatively, while viewing a group, Group Manager 44 will displaya “modify group” button. Selecting that button allows the user torequest a modification to the group being viewed, if the user hassufficient privileges. In step 1402, Group Manager 44 provides a list ofauxiliary classes that can be added or removed from the existing group.In an alternative embodiment, Group Manager 44 provides a list ofattributes to add or remove, with each of the attributes beingassociated with auxiliary classes. The auxiliary classes and/orattributes to be added or removed are reported to the user via agraphical user interface. Next to each class (or each attribute) is acheck box. The user can check the check box to indicate that the class(or attribute) should be added. The user can uncheck check box toindicate that the class (or attribute) should be removed. In step 1404,the selection of classes (or attributes) to be added and removed arereceived by Group Manager 44 from the graphical user interface andstored. In step 1406, those auxiliary classes selected to be removed arethen removed from the group object including removing those attributesfrom the group object. In step 1408, the auxiliary class selected to beadded and their associated attributes are added to the group object.After step 1408, the group can be used as any other group; for example,a user can be authorized to access a resource based on attributes of ormembership in a group.

[0278]FIG. 33 is a flowchart describing the process for removingauxiliary classes and their associated attributes from an object. Instep 1430, Group Manager 44 selects one of the classes that have beenmarked for removal. In step 1432, Group Manager 44 determines whichattributes are associated with that selected auxiliary class. Theattributes identified in step 1432 do not include attributes that arepart of a class that is not being removed. In step 1434, thoseattributes that are determined in step 1432 are removed from the groupobject. When the attributes are removed, all data stored in thoseattributes is deleted. In step 1436, the actual auxiliary class isremoved from the group object. In step 1438, all auxiliary classes thatare superior classes to the currently selected auxiliary class (see step1430) are removed from the group object. In many instances, theauxiliary classes are part of an object oriented hierarchy whereauxiliary classes can be subclasses of other classes (called superiorclasses). A subclass inherits from the superior class. In many cases, aparticular auxiliary class may have a superior class, which has asuperior class, which has a superior class, and so on. Thus, the chainof superior classes from the auxiliary class will go all the way up thetree to the root class. Therefore, some auxiliary classes will have manysuperior classes. All of the superior classes for a particular auxiliaryclass are removed when that auxiliary class is removed. Step 1436,however, does not remove a superior class, if that superior class isalso superior to another auxiliary class that is part of the object andis not being removed. There is no need to remove the attributes of thesuperior classes because all those attributes have been inherited by theauxiliary class and already removed in step 1434. In step 1440, it isdetermined whether there are any more auxiliary classes to be removed.If there are more auxiliary classes to be removed, then the method loopsto step 1430. If there are no more auxiliary classes to remove, then theprocess is complete. Note that some directories do not allow for themodification of the object class attribute; therefore, in those cases,only the attributes are removed.

[0279]FIG. 34 is a flowchart describing a process for adding to thegroup object those auxiliary classes that have been marked for addition.In step 1460, Group Manager 44 chooses an auxiliary class for adding tothe group object from those auxiliary classes marked for addition. Instep 1462, the chosen auxiliary class is added to the group object. Instep 1464, all superior classes of the auxiliary class chosen in step1460 that are not already part of the group object are added to thegroup object. In step 1466, all of the attributes from the auxiliaryclass selected in step 1460 are added to the group object. In step 1468,it is determined whether there are any more auxiliary classes to add. Ifthere are more auxiliary classes to add, then the method loops back tostep 1460. If there are no more auxiliary classes to add, then themethod of FIG. 34 is completed.

[0280] The ability to add or remove from an existing group at runtimeprovides greater flexibility in defining the content for groups.Furthermore, the removal of an auxiliary class provides a means to bulkdelete a set of attributes because removing an auxiliary class will, inone embodiment, delete all attributes for the removed class. Finally,the ability to add or remove from an existing group provides for lesscoupling between a group schema and group entries. For example, if theschema changes such that a group auxiliary class is removed, only thosegroup entries that have that auxiliary class need to be updated.

[0281] The Identity System also includes an “Advanced Group” auxiliaryobject class that contains the attributes necessary to implement some ofthe unique functionalities described above. Administrators can attachthe “Advanced Group” to a group in order to provide values forattributes that control features such as Subscription/Unsubscription andDynamic Membership. In one embodiment, the “Advanced Group” consists ofone auxiliary class that includes the attributes listed below. Inanother embodiment, the “Advanced Group” consists of a plurality ofclasses.

[0282] The attributes in the “Advanced Group” related toSubscription/Unsubscription are:

[0283] obgroupsubscriptiontype—stores the subscription policy

[0284] obgroupsubscriptionfilter—stores an LDAP rule used with the Openwith Filter policy

[0285] obgroupsubscribenotification—stores values of either “subscribe”or “unsubscribe” indicating whether or not the user should receive anemail upon subscribing or unsubscribing from the group.

[0286] obgroupsubscribemessage—stores a customized message the userreceives upon subscribing to the group

[0287] obgroupunsubscribemessage—stores a customized message the userreceives upon unsubscribing from the group

[0288] The attributes related to Dynamic Membership are:

[0289] obgroupdynamicfilter—stores the LDAP rule that defines thegroup's dynamic membership

[0290] obgrouppuredynamic—stores either “true” or “false” indicatingwhether or not static members can be added to the group

[0291] The following two attributes belong to neither of the twocategories above but are included here for completion:

[0292] obgroupsimplifiedaccesscontrol—stores the initial attributeaccess control policy applied to newly created group

[0293] obgroupadministrator—stores the user selected as the groupadministrator.

[0294] The system of FIG. 1 provides users with a variety of interfaceoptions. For example, the system supports users with traditionalbrowsers by providing for communication using HTTP and Hypertext Mark-upLanguage (“HTML”). The system also supports interfaces to third partyapplications, proprietary browsers and others by providing forcommunication using Extensible Mark-up Language (“XML”). Embodiments ofthe present invention provide further flexibility by facilitating theuse of custom XML templates to generate HTML and XML responses.

[0295]FIG. 35 shows a process employed by Identity Server 40 to provideresponses to users' requests. Identity Server 40 receives the requestfrom Web Server 20 (step 1600). In one embodiment of the presentinvention, Identity Server 40 is capable of receiving HTML requests viathe HTTP protocol, as well as XML requests via the SOAP protocol (orother protocols). One example of an HTML request over HTTP (or otherprotocols), appears as follows:

[0296] http://host:port/appname.cgi?param1=valuel&param2=val2 . . .

[0297] The “http” indicates the request is controlled by the HTTPprotocol. The host:port field identifies the host that is the target ofthe request and port on that host. The appname field identifies theapplication for Identity Server 40 to perform, such as User Manager,Group Manager, or Organization Manager. The parameter fields (param1,param2, . . .) identify parameters employed by the identifiedapplication. For example, param1 may be a function the identifiedapplication performs, and param2 may be a variable or other informationrequired for carrying out the function. One example of a function is asearch program that searches Directory Server 36 for entries withattributes corresponding to values in the request's parameters. In thisexample, the parameters may require Identity Server 40 to searchDirectory Server 36 for the employee entry for John Smith.

[0298] When the SOAP protocol is employed, Identity Server 40 receives arequest similar to the example described above, with a host:port valuethat informs Identity Server 40 that the SOAP protocol is in use. Therequest includes an XML document encapsulated in the SOAP protocolformat. The following provides an example of such a request: © Oblix,Inc., 2001 <?xml version=“1.0”?> <SOAP-ENV:Envelopexmlns:oblix=“http://www.oblix.com”xmlns:SOAP-ENV=“http://schemas-xmlsoap.org/soap/envelope/”><SOAP-ENV:Body> <oblix:authentication xmlns:oblix=“http://www.oblix.com”type=“<fill in authentication type>”> <oblix:login>loginname</oblix:login> <oblix:password>password</oblix:password></oblix:authentication> <oblix:request application=“<fill in applicationname>” function=“<fill in function name>”> <oblix:params> <oblix:paramname=“<fill in parameter name>”><fill in parameter value></oblix:param></oblix:params> </oblix:request> </SOAP-ENV:Body> <SOAP-ENV:Envelope>

[0299] The above listed text is the backbone of a standard SOAP requestwith the italicized text representing variables that change betweenrequests. The “oblix:authentication” directive identifies the type ofuser authentication to be employed. The authentication directiveincludes a type parameter that corresponds to an authenticationoperation. One authentication type calls for a user's login ID andpassword. These parameters are provided in the “oblix:login” field and“oblix:password” field. Alternate implementations of authenticationoperations include evaluating a user's cookie and/or requiring the userto submit a challenge phrase.

[0300] The “oblix:request” directive provides the necessary informationfor identifying the user's request. Attributes provided within the“oblix:request” section are application name, function name, andparameters employed by the function.

[0301] Once a request is received (step 1600, FIG. 35), Identity Server40 determines whether any pre-processing is required for the request(step 1602). Decryption is an example of one pre-processing operation.If pre-processing is required, Identity Server 40 performs thepre-processing operation (step 1604). Once pre-processing is complete orif no pre-processing is required, Identity Server 40 translates therequest (step 1606). In one implementation, Identity Server 40translates the request by identifying all programs to be performed inresponse to the request and the format for outputting the results fromeach program. Process steps for carrying out the translation aredescribed in greater detail below.

[0302] Identity Server 40 performs the request (step 1608) after therequest is translated. In performing the request, Identity Server 40retrieves and manipulates data in accordance with the functionsidentified in the request. After the request is performed, IdentityServer 40 prepares an Output XML (step 1610). The Output XML is a datafile organized in accordance with formatting directions retrieved duringthe translation operation (step 1606). In one embodiment of the presentinvention, the Output XML is formed using a XML template obtained duringthe translation process (step 1606) and display characteristics. The XMLtemplate provides a data structure for the Output XML. The use of XMLtemplates and display characteristics is described in greater detailbelow.

[0303] After preparing the Output XML, Identity Server 40 determineswhether any post-processing is to be performed (step 1612).Post-processing may include operations such as encryption. Embodimentsof the present invention also provide for post-processing operationsthat further customize the Output XML. If post-processing is to beperformed, Identity Server 40 carries out the post-processing operation(step 1614).

[0304] After completing post-processing or if no post-processing isnecessary, Identity Server 40 determines whether client-side processingwill be used (step 1616). In client-side processing, Identity Server 40provides the Output XML data file to the requesting client through WebServer 20. In contrast, the client may elect to have Identity Server 40perform server-side processing. In server-side processing, IdentityServer 40 processes the Output XML to prepare a response to the request.

[0305] If client-side processing is chosen, Identity Server 40 preparesa client-side response (step 1620). In one implementation of the presentinvention, two different client-side responses are possible. The clientmay receive only the Output XML or both the Output XML and references toa set of XSL stylesheets that contain directives for converting theOutput XML into an HTML display. In various embodiments of the presentinvention, the set of XSL stylesheets may contain one or multiple XSLstylesheets. The user (or client) then formats the Output XML forpresentation or any other purpose the user desires. If client-sideprocessing is not selected, Identity Server 40 prepares a server-sideresponse (step 1618). In one embodiment, Identity Server 40 combines theOutput XML with a XSL stylesheet to obtain a HTML response for theclient.

[0306] In one embodiment of the present invention, Identity Server 40determines whether to perform client-side or server-side processing byexamining a processing parameter in the request. In a furtherimplementation, the processing parameter also indicates the desiredclient-side response from Identity Server 40, namely Output XML and XSLstylesheet references or Ouput XML and no XSL stylesheet references. Ifthe processing parameter is set to equal “xm1noxsl,” Identity Server 40prepares a client-side processing response including Output XML and nostylesheet references. If the processing parameter is set to equal“xml,” Identity Server 40 prepares a client-side processing responseincluding both output XML and references to a set of XSL stylesheets theclient can access. If no processing parameter appears in the request,Identity Server 40 defaults to preparing a server-side processingresponse. In further embodiments, the request can also include aparameter expressly identifying a XSL stylesheet for Identity Server 40to employ in preparing either a server-side or client-side response.

[0307] In another version of the present invention, Identity Server 40employs a predefined list to determine whether to provide client-sideprocessing or server-side processing. The list identifies browsers thatdesire client-side processing. If Identity Server 40 receives a requestfor a browser on the list, Identity Server 40 performs client-sideprocessing. Otherwise, Identity Server 40 performs server-sideprocessing. In a further embodiment, the list distinguishes betweenclient-side processing providing Output XML and XSL stylesheetreferences and client-side processing providing Output XML and no XSLstylesheet references. The list may be updated by clients.

[0308] Once a response has been prepared, Identity Server 40 forwardsthe response to Web Server 20 (step 1622), which forwards the responseto the client (step 1624).

[0309]FIG. 36 shows the steps taken by Identity Server 40 in performinga pre-processing operation (step 1604, FIG. 35). Identity Server 40retrieves a pointer to the pre-processing application from the eventcatalog (step 1640). Identity Server 40 then performs the pre-processingapplication (step 1642).

[0310] In order to perform request translation (step 1606, FIG. 35),Identity Server 40 maintains program service 1660 and XML data registry1670, which are both depicted in FIG. 37. Program service 1660 containsa list of the programs supported by applications running on IdentityServer 40. Each function in the request corresponds to at least oneprogram listed in program service 1660. Each program listing in programservice 1660 contains a pointer to a program, as well as any peripheralprograms to be performed in conjunction with the listed program. Inalternate embodiments of the present invention, the peripheral programscan be identified in the request or a register file in XML data registry1670. An example of a peripheral program is the display of a navigationbar that accompanies the display of a request's results.

[0311] XML data registry 1670 contains registration files. Eachregistration file corresponds to at least one program or peripheralprograms listed in program service 1660. Each registration file containsinformation necessary for structuring the output of a program's result.Identity Server 40 maintains a set of XML templates 1672, XML schemas1674, and XSL stylesheets 1676. Each registration file in data registry1670 contains a pointer to an XML template, an XML schema and XSLstylesheet. The application of templates and stylesheets will beexplained below in greater detail. Schemas provide information toIdentity System users for establishing display characteristics.

[0312]FIG. 38 illustrates steps performed by Identity Server 40 totranslate a request (step 1606, FIG. 35). In step 1700, Identity Server40 identifies programs corresponding to functions called for in therequest, including peripheral programs. For each program explicitlyidentified in the request, Identity Server 40 finds a correspondingentry in program service 1660. The corresponding entry contains apointer to the explicitly identified program, as well as pointers to allperipheral programs to be performed in conjunction with the explicitprogram. In one embodiment, all explicitly identified programs forworkflow related requests include peripheral programs for providing aworkflow function navigation bar, a search bar/window, and a standardnavigation bar. Other programs include peripheral programs for providinga standard navigation bar and a search window in a window with anydisplayed program results.

[0313] Identity Server 40 completes the request translation byretrieving XML templates and XSL stylesheets. Identity Server 40retrieves a XML template for each identified program and peripheralprogram (step 1702). Identity Server 40 retrieves each template from aregister file in data registry 1670. Each register file corresponds toat least one combination of an application and a program. IdentityServer 40 retrieves a XSL stylesheet for each identified program andperipheral program (step 1706). In one embodiment, Identity Server 40retrieves each stylesheet from the same register files containing theretrieved XML templates.

[0314] The following provides an example of a registration file in oneembodiment of the present invention: © Oblix, Inc., 2001 <?xmlversion=“1.0”?> <ObProgramRegistry> <ObApplicationname=“the_application_name”> <ObProgram name=“a_program_name”> <ObButtonname=“a_button_name”/> <ObButton name=“yet_another_button_name”/><ObButton name=“and_maybe_more_button_names”/> . . . . . . <ObTemplatename=“templatename.xml”/> <ObStyleSheet name=“stylesheetname.xsl”/><ObSchema name=“XML_schema_name.xsd”/> </ObProgram> <ObProgramname=“another_program_name”> <ObStyleSheetname=“Its_stylesheetname.xsl”/> <ObButtonname=“a_button_associated_with_it”/> <ObSchemaname=“Its_XML_schema_name.xsd”/> </ObProgram> <ObProgramname=“and_so_on”> . . . . . . </ObProgram> . . . . . . </ObApplication></ObProgramRegistry>

[0315] The ObProgramRegistry directive identifies the file as aregistration file. The ObApplication instruction identifies anapplication. The ObProgram instruction identifies a program. IdentityServer 40 uses the ObApplication and ObProgram values to identify theappropriate register file for retrieving a program's XML template, XMLschema, and XSL stylesheet. For each program, Identity Server 40 locatesthe register file with the ObApplication and ObProgram values matchingthe request's application and program (steps 1702 and 1706).

[0316] Information within an ObProgram directive provides the template,schema and stylesheet for formatting a program's results as Output XMLand an HTML document. The ObTemplate field specifies an XML template tobe used with the program specified in the ObProgram field. TheObStyleSheet field identifies the XSL stylesheet for the program. TheObSchema field identifies the schema for the program. Identity Server 40retrieves the identified template and stylesheet in steps 1702 and 1706for each program identified in step 1700.

[0317] In further embodiments, the register file contains additionalinformation related to preparing an output display for a program'sresult. For example, one or multiple “ObButton” directives can beassociated with a program combination when a button is to be displayedalong with program results. The button field is used in preparing thebutton display for Identity Server 40. For example, it may beappropriate to display an acceptance button along with programresults—calling for a user to accept displayed data. A typical buttonidentifies the following characteristics: (1) graphical display; (2)mouse over text; and (3) link that will be invoked when the button isselected by the user. In one implementation, button information isdynamically determined, as opposed to being defined in a template.

[0318] The following is an example of an XML template employed with aprogram for retrieving personal information for people with the lastname Smith: © Oblix, Inc., 2001 <?xml version=“1.0”?> <Company><PersonalInformation> <Email> <oblix:data attrname=“mail”/> </Email><Name> <oblix:attribute name=“Smith”> <oblix:data attrname=“sn”/></oblix:attribute> <oblix:data attrname=“cn”/> </Name></PersonalInformation> <oblix:link href=“location.xml”/> </Company>

[0319] This template indicates that a program retrieves personalinformation from entries in a company's directory server that have alast name “Smith.” The personal information retrieved includes theperson's e-mail and name. The XML template provides directives to obtainthis information. The <oblix:data attrname=“mail”/>directive specifiesmail as an attribute name for the desired e-mail address value. Theprogram responds by replacing the <oblix:data attrname=“mail”/>elementwith the e-mail value retrieved by the program. This element is alsoreferred to as a direct proxy value.

[0320] The <oblix:attribute name=“Smith”><oblix:dataattrname=“sn”/></oblix:attribute>directive calls for the program toselect an entry from the directory server with a value in the surname(sn) attribute corresponding to “Smith.” The <oblix:dataattrname=“cn”/>instruction is another direct proxy calling for thecomplete name (cn) attribute in the selected entry. The <oblix:linkhref=“location.xml”/directive links the present template to another XMLtemplate specified by the location.xml name.

[0321] The following shows the resulting XML template after the programhas been executed and the program fills in direct proxies in the XMLtemplate. © Oblix, Inc., 2001 <?xml version=“1.0”?> <Company><PersonalInformation> <Email> j.smith@company.com </Email> <NamelastName=“Smith”> John Smith </Name> </PersonalInformation> <Location><FloorNumber value=“6”/> </Location> </Company>

[0322] The program located one person with a last name of Smith, namelyJohn Smith. The program returned John Smith's e-mail asj.smith@company.com and John Smith's name as “John Smith.” Thereferenced “location.xml” template was also integrated into the existingtemplate to indicate that John Smith resides on the 6^(th) floor.

[0323] The use of templates and stylesheets provides users with a greatdeal of flexibility and control. Templates and stylesheets can bemodified to address the unique needs of system users. Different systemusers employing the same programs can create different displays of theprogram's results. Users and/or system administrators implementcustomized templates and stylesheets in desired register files.

[0324]FIG. 39 provides a more detailed view of the steps taken byIdentity Server 40 to prepare an Output XML for a request using XMLtemplates and attribute display characteristics (step 1610, FIG. 35).Identity Server 40 first prepares an XML data structure (step 1730). TheXML data structure is an organization of data based on the XML templatescorresponding to the request's programs. The XML data structure combinesthe XML templates from each program to form a single data structure.This enables Identity Server 40 to provide a single response to arequest instead of a response for each program in the request.

[0325] Identity Server 40 maps data retrieved in performing therequest's programs into the XML data structure. An example of an XMLdata structure for the XML template shown above appears below in Table5: TABLE 5 Proxies Retrieved Attribute Values Email j.smith@company.comComplete Name John Smith

[0326] In the XML data structure, the left-hand column lists the namesof data server entry attributes retrieved by the program. These are alsoreferred to as direct proxies. The right-hand column corresponds to theretrieved attribute values for the direct proxies. Identity Server 40fills each right-hand column cell with the corresponding data for thedirect proxy. As shown in Table 5 above, the direct proxy field for thee-mail address attribute is filled with the j.smith@company.com value,and the direct proxy field for the complete name attribute is filledwith John Smith.

[0327] In some instances, an XML template indirectly defines data to beretrieved-calling for data from an attribute based on the status ofanother attribute. For example, a search program may call for the nameand e-mail address for each direct report of John Smith. In thisexample, an entry's name and e-mail address attributes for a person arereturned, if another attribute in the entry identifies John Smith as theperson's direct manager. The XML template shown below supports thissearch: <Person> <Direct Report> <Name> <oblix:data attrname=“cn”/></Name> <Email> <oblix:data attrname=“mail”/> </Email> </Direct Report></Person>

[0328] The above XML template indicates that a name and e-mail addressis to be retrieved for each direct report of John Smith. In DirectoryServer 36, no entry identifies the direct reports of John Smith.Instead, the entry for each person identifies the person's directmanager. Identity Server 40 queries Directory Server entries andretrieves name and e-mail address information from those entries withJohn Smith in the direct manager attribute. The <oblix:dataattrname=“cn”/>and <oblix:data attmame=“mail”/>directives in thetemplate are indirect proxy values for the data to be retrieved byIdentity Server 40.

[0329] Template elements calling for indirect proxies are also mappedinto the XML data structure. Prior to mapping these elements into theXML data structure, Identity Server 40 prepares a data structureidentifying each of the entries used to obtain the indirect proxyvalues. An example data structure for the above XML template appearsbelow in Table 6: TABLE 6 Direct Report Entry Direct Report 1 Bob SmithDirect Report 2 Gordon Smith

[0330] The indirection structure in Table 6 identifies the entries forBob Smith and Gordon Smith as direct reports of Bob Smith. Thisindicates that Identity Server 40 will retrieve indirect proxy valuesfrom the data store entries for Bob Smith and Gordon Smith. IdentityServer 40 adds data for the indirect proxy values for the Bob Smith andGordon Smith entries to the XML data structure, which can contain bothdirect and indirect proxies. The resulting XML data structure appearsbelow in Table 7: TABLE 7 Proxies Retrieved Attribute Values Emailb.smith@company.com Name Bob Smith Email g.smith@company.com Name GordonSmith

[0331] The XML data structures shown above are just examples of XML datastructures that can be prepared in accordance with the presentinvention. As those skilled in the art will recognize, the contents ofXML data structures can vary widely as different XML templates andprograms are employed.

[0332] After preparing the XML data structure (step 1730, FIG. 39),Identity Server 40 transforms the XML data structure into Output XML(step 1732). Identity Server 40 obtains attribute displaycharacteristics for the retrieved attributes in the XML data structure.The display characteristics establish the display format of attributedata in the XML data structure. Attribute display characteristicsidentify a display type and relevant information for the display. Forexample, a text box display type and the length of the text box.

[0333] In one embodiment, Identity Server 40 obtains attribute displaycharacteristics from directory entries in Directory Server 36. EachDirectory Server entry corresponds to a different attribute type. Foreach attribute, Identity Server 40 locates a corresponding directoryentry, which provides the attribute's display characteristics. In onesuch embodiment, a system administrator creates all the displayattribute directory entries when Identity System 40 is configured. Inalternate embodiments of the present invention, the directory entriesare replaced by tables, data structures, or other means that relatedisplay characteristics to attributes so the display characteristics canbe obtained by Identity Server 40.

[0334] As explained above, the Output XML is combined with XSLstylesheets to obtain HTML displays. XSL stylesheets interpretdirectives integrated into the Output XML by the attribute displaycharacteristics—providing instructions to Identity Server 40 or anyother processing engine to implement the formatting called for by theattribute display characteristics. For example, the attribute displaycharacteristics may have integrated directives into the Output XMLindicating that a name, such as John Smith, is to be displayed accordingto a particular type. The identified type corresponds to a set ofinstructions in an XSL stylesheet that direct a processor to display thevalue John Smith with a particular font and size. In one example, thedisplay type instructions in the XSL stylesheet indicate that the nameJohn Smith is to be displayed in an Arial font with 12 point typeface.

[0335]FIG. 40 illustrates steps for performing post-processing (step1614, FIG. 35). These steps are very similar to the above-describedpre-processing operation (step 1604, FIG. 35). Identity Server 40retrieves a pointer to the post-processing application in the eventcatalog (step 1750). Identity Server 40 then performs thepost-processing application (step 1752).

[0336] By employing post-processing, a client can create a plug-inprogram running on Identity Server 40 that captures and modifies theOutput XML prior to Identity Server 40 returning a request response.This provides users of Identity Server 40 with great flexibility andcontrol over the content and format of request responses. For example, auser can modify the Output XML to insert a customized display typedirective or remove unwanted data.

[0337]FIG. 41 describes the operations performed by Identity Server 40to prepare a client-side response (step 1620, FIG. 35). Identity Server40 determines whether the client wishes to receive references to a setof XSL stylesheets (step 1780). If the client wishes to receive XSLstylesheet references, Identity Server 40 prepares a response includingOutput XML and the associated XSL stylesheet references (step 1784).Otherwise, Identity Server 40 prepares a response with Output XML and noXSL stylesheet references (1782). Client-side processing is useful inseveral applications. In one instance, a client may wish to receive onlyOutput XML for a third party application that does not require anydisplay. This makes the display rules and information in the stylesheetsuseless. In another instance, a client's browser may do a superior jobof combining Output XML and XSL stylesheets to form an output display.In this instance, client-side processing allows the client to use theirown browser to combine Output XML and XSL stylesheets. In oneembodiment, XSL stylesheet references are provided in the form ofUniform Resource Identifiers (also known as Uniform Resource Locators)in the Output XML.

[0338]FIG. 42 shows the operation of Identity Server 40 in preparing aserver-side response (step 1628, FIG. 35). Identity Server 40 combinesthe Output XML with its associated XSL stylesheets (step 1800). IdentityServer 40 then formats the resulting combination as an HTML outputdocument (step 1802).

[0339] One of the peripheral programs frequently performed inconjunction with a user's expressly requested program is the generationof a navigation bar. The navigation bar is displayed along with theresult of a user's expressly identified program—enabling the user tonavigate within the request response and other related areas. Forexample, the navigation bar lets a user scroll through the text of theresponse and jump to related data in Directory Server 36. Someimplementations of Identity Server 40, however, provide users withdifferent levels of access to Directory Server 36 and functionsperformed by Identity Server 40. Identity Server 40 provides fordisplaying different navigation bars based on user access privileges.

[0340]FIG. 43 shows steps performed by Identity Server 40 that providedifferent navigation bars based on a user's access privileges. Asexplained above, Identity Server 40 retrieves a navigation barperipheral program from program service 1660 as part of the translationprocess (step 1606, FIG. 35 and step 1700, FIG. 38). Identity Server 40also retrieves an XML template and XSL stylesheet for the navigation barprogram (steps 1702 and 1706, FIG. 38). In one embodiment of the presentinvention, Identity Server 40 maintains a set of navigation bartemplates for a program, as opposed to a single navigation bar template.Each navigation bar template corresponds to a different user type whereeach user type has different access privileges. In retrieving an XMLtemplate for the navigation bar, Identity Server 40 carries out thesteps shown in FIG. 43. Identity Server 40 selects the navigation barXML template corresponding to the user issuing the request (step 1820).Identity Server 40 then selects portions of the navigation bar templatethat are relevant to the user's explicitly requested program (step1821). In some instances, portions of the selected navigation bartemplate may not be relevant to the request response. The selectedportions of the navigation bar template form the XML template for thenavigation bar program. Identity Server 40 employs the resulting XMLtemplate to prepare a response in the manner described above withrespect to FIGS. 35-42.

[0341] Requests for data received by the Identity System frequentlyrequire repeated access to the same entries in Directory Server 36.Continually retrieving this information through Directory Server 36slows operation and wastes server bandwidth. Therefore, Identity Server40 provides each active request with a cache to reduce the number ofdata store accesses.

[0342] Each request is assigned to a thread of operation. Each threadhas access to a small amount of memory in Identity Server 40 that isreferred to as thread local storage. FIG. 44 provides an illustration ofthread 1826, which resides in Identity Server 40 and contains threadlocal storage 1827. In accordance with the invention, thread localstorage 1827 contains cache pointer 1828, which points to cache object1829. Cache object 1829 is reserved for caching data from entries inDirectory Server 36 that are accessed by the request assigned to thread1826.

[0343] In one embodiment, cache object 1829 is a write through cachethat is deleted once a request completes operation in thread 1826. Inone implementation, Identity Server 40 does not update cache object 1829to maintain coherency with either cache objects in other threads ofexecution or changes made to the data store by other threads ofexecution. Requests typically expect data retrieved during one segmentof the request's performance to remain the same, unless changed by therequest itself. In alternate embodiments of the present invention,Identity Server 40 updates cache object 1829 to maintain coherencybetween cache object 1829, the data store, and other cache objects.

[0344]FIG. 45 illustrates steps performed in one version of theinvention to provide request based caching. Web Server 20 receives arequest (step 1830) and assigns the request to thread of execution 1826in Identity Server 40 (step 1832). No request other than the oneassigned to thread 1826 has access to cache object 1829. At some pointduring the Identity Server's execution of the request, the request callsfor Identity Server 40 to perform a data store access command (step1833). At this point, Identity Server 40 begins implementing cachingoperations.

[0345] Identity Server 40 determines whether the request's data storecommand is a query or a write to data store 36 (step 1834). DirectoryServer 36 is referred to here as a data store, since there is nothingdirectory server specific in the request-based caching. The embodimentshown in FIG. 45 operates in many types of environments including flatfiles and RDBMS. If the attempted access is a query, Identity Server 40determines whether the queried entry is already stored in cache object1829 (step 1836). If the queried entry resides in cache object 1829,Identity Server 40 retrieves the requested entry from cache 1829 (step1840). Otherwise, Identity Server 40 retrieves the entry from the datastore through data store 36 (step 1838). Identity Server 40 then copiesthe entry into cache object 1829 so the data will be available for lateraccesses (step 1842).

[0346] If the attempted data store access is a write (step 1834),Identity Server 40 determines whether the requested memory location isstored in cache object 1829 (step 1844). If the entry is stored in cacheobject 1829, Identity Server 40 removes the old entry in cache object1829 (step 1846) and writes the data supplied by the request into cacheobject 1829 (step 1845). Identity Server 40 also writes the same datainto the data store (step 1848). If no cache entry exists for therequested entry, Identity Server 40 creates a space for the entry incache 1829 and writes the data to cache 1829 (step 1845). IdentityServer 40 also writes the data to the data store through data store 36(step 1848).

[0347] The process shown in FIG. 45, beginning with step 1833 describedabove, is repeated for each data store access command in a request. Oncethe request is completed, cache object 1829 is destroyed.

[0348] As described above, clients submit requests to the IdentitySystem asking for information on requesting tasks to be performed. Theserequests can be submitted via HTTP, XML documents, or other means. Insome embodiments of the present invention, multiple Identity Servers areemployed to increase the throughput of the Identity System. In suchembodiments, requests are assigned to Identity Servers so as to balancethe load of each Identity Server. In some instances a request mayexecute a function that requires a primary Identity Server handling therequest to communicate with another Identity Server.

[0349] One example of need for inter-server communications arises incaching applications. In some implementations, Identity Servers eachmaintain caches for data that is frequently used by requests. Forexample, each Identity Server maintains a workflow definition cachecontaining workflow data. When a request alters a workflow, the workflowdefinition cache in every Identity Server must be flushed, since thecache data is no longer accurate. The primary Identity Server handlingthe request must communicate with all other Identity Servers to instructthem to flush their workflow definition caches. Identity Servers in oneembodiment of the present invention are equipped to perform suchinter-server communications.

[0350]FIG. 46 shows a block diagram of two identity servers that areequipped to communicate with each other in accordance with the presentinvention. Identity Server 1900 contains a set of function modules 1904.Each function module contains instructions for carrying out a programthat may be called for by a request. Function module set 1904communicates with a set of caches 1906. Caches in set 1906 contain datafrequently used by function modules in set 1904. The following cachesare representative of those in set 1906: (1) Access Control PolicyCache; (2) System Specific Data Cache; (3) Workflow Definition Cache;(4) X Structure Cache; (5) Server Information Cache; (6) ApplicationInformation Cache; and (7) Master Audit Policy Cache.

[0351] Identity Server 1900 also includes management service 1910,management registry 1908, and request handler 1912. Management service1910 provides an application programming interface for functionalmodules to call when remote access of another Identity Server isrequired. Management registry 1908 stores pointers to functions in set1904. In one embodiment of the present invention, management registry1908 is a hash table. Request handler 1912 receives communicationrequests from other identity servers.

[0352] Identity Server 1902 includes function module set 1914, cache set1916, management service 1920, management registry 1918, and requesthandler 1922. The components identified in Identity Server 1902 operatethe same as the similarly named components in Identity Server 1900.

[0353] Request handler 1912 is coupled to management service 1920 toreceive inter-server communications. Request handler 1922 is coupled tomanagement service 1910 to receive inter-server communications.

[0354] In one embodiment of the present invention, inter-servercommunications include a remote request to implement functions. In onesuch embodiment, function parameters accompanying a remote request aretransferred among identity servers in a key-value format, which appearsbelow:

{length}key=val{length}key val . . .

[0355] The “{” symbol indicates the beginning of a parameter. The “val”field is the parameter being passed. The “length” field identifies thenumber of bytes in the val field. The “}” symbol indicates the end ofthe length field. The “key” field identifies the name for the parameter.In this embodiment, each remote function is able to encode and decodekey-val parameters.

[0356]FIG. 47 illustrates steps for performing inter-servercommunications for one embodiment of the present invention. During theperformance of a user request, a function module in set 1904 issues arequest for a remote operation to management service 1910 (step 1940).Management service 1910 is referred to as the local management service,since it resides in the Identity Server where the remote requestoriginated. Management service 1910 first processes any portion of theremote request that needs to be carried out locally in Identity Server1900 (step 1942). Next, remote Identity Server 1902 processes the remoterequest (step 1944). Steps 1942 and 1944 can be exchanged in alternateembodiments of the present invention so that remote Identity Server 1902services the remote request before local Identity Server 1900.

[0357]FIG. 48 illustrates steps taken by Identity Server 1900 to carryout local processing of the remote request (step 1942, FIG. 47).Management service 1910 determines whether the remote request requiresany local operations (step 1960). If a local operation is required,management service 1910 identifies a function module in set 1904 forcarrying out the local operation. Management service 1910 makes thisidentification by supplying the requested local operation to managementregistry 1908. Management registry 1908 identifies the function modulein set 1904 for carrying out the requested local operation. Managementservice 1910 executes the selected function module (step 1964).

[0358] After executing the local operation or if no local operation isrequired, management service 1910 opens a message channel for providingthe remote request to remote Identity Server 1902 (step 1966).Management service 1910 then issues the remote request to remoteIdentity Server 1902 (step 1968). In the embodiment shown in FIG. 46,management service 1910 opens up a communication channel with IdentityServer 1902 and provides the remote request to server 1902. In alternateembodiments, however, more than two Identity Servers are employed in theIdentity System. In such embodiments, local Identity Server 1900 opensmessage channels with all the other remote Identity Servers and issuesthe remote request to them.

[0359]FIG. 49 illustrates steps taken by a remote identity server, suchas Identity Server 1902, to respond to a remote request from anotherIdentity Server. Request handler 1922 receives the remote request fromlocal management service 1910 (step1990). Request handler 1922identifies a function module in set 1914 for carrying out the remoterequest (step 1992). Request handler 1922 makes this identification bysupplying the remote request to management registry 1918, whichidentifies the corresponding function module in set 1914. Next, IdentityServer 1902 executes the identified function module (step 1994).

[0360]FIGS. 50 and 51 combine to show the steps taken by local andremote Identity Servers in response to function modules calling forcache flushing. FIG. 50 illustrates steps taken by local Identity Server1900 to execute a function module for cache flushing (step 1964, FIG.48). Identity Server 1900 blocks all new requests from being serviced(step 2010). Identity Server 1900 then determines whether any requestsare currently being serviced within Identity Server 1900 (step 2012). Ifrequests are currently being serviced, Identity Server 1900 waits untilthe servicing of all these requests has been completed (step 2012). OnceIdentity Server 1900 is no longer servicing any requests, IdentityServer 1900 sends a non-blocking cache flush request to remote IdentityServer 1902 (step 2013). A non-blocking request does not require localIdentity Server 1900 to wait for remote Identity Server 1902 to servicethe request before resuming local actions. Identity Server 1900 flushesthe identified cache in set 1906 (step 2014). After the flush, IdentityServer 1900 resumes servicing new requests (step 2016). In theembodiment shown in FIG. 50, step 2013 carries out steps 1966 and 1968shown in FIG. 48 by issuing a flush request to remote Identity Server1902. In alternate embodiments, step 2013 is removed and steps 1966 and1968 are carried out after local Identity Server 1900 flushes the localcache (step 2014) and unblocks new requests (step 2016).

[0361]FIG. 51 shows the operations executed by remote Identity Server1902 to execute a function module for flushing a cache in set 1916 (step1994, FIG. 49). Remote Identity Server 1902 blocks all new requests frombeing serviced (step 2040). Identity Server 1902 then determines whetherany requests are currently being serviced (step 2042). If any requestsare currently being serviced, Identity Server 1902 waits until theservicing of all these requests is complete (step 2042). Once allrequest servicing is terminated, Identity Server 1902 flushes theidentified cache in cache set 1916 (step 2044). Identity Server 1902then resumes the servicing of new requests (step 2046).

[0362] In one embodiment, the present invention provides for customizedcertificate management processes. Certificates are electronic documentsused to verify the identity of an entity such as a user, group ororganization. A well known standard defining certificate formats is theX.509 standard for certificates. In general, a certificate containsinformation about an entity, including a public key for performingencryption. A certificates holder maintains a secret copy of acorresponding private key that is used for decryption. Certificatesemployed in one embodiment of the present invention include thefollowing fields: (1) VEND—certificate's expiration date; (2)VSTART—certificate validity start date; (3) ISSUER -certificate holder'sdistinguished name (dn); (4) EMAIL—certificate holder's e-mail address;(5) SERIAL- certificate serial number; (6) VERSION—certificate versionnumber; (7) ALGOID—certificate algorithm identifier; (8)PUBLICKEY_ALGOID—public key algorithm identifier; (9) PUBLICKEY—publickey value of the certificate; (10) ISSUER_SIGNATURE_ID—certificateholder's signature algorithm identifier; and (11) SUBJECT—subject of thecertificate.

[0363] When a first person wants to establish a secure connection with asecond person, the first person sends the second person theircertificate. The second person obtains the first person's public keyfrom the certificate. When sending messages to the first person, thesecond person uses the public key to encrypt the message. The firstperson uses their private key to decrypt the message. The first personcan provide a secure response to the second person by using the secondperson's public key, which is attached to the second person'scertificate.

[0364] Embodiments of the present invention provide for establishingdifferent sets of criteria for obtaining a certificate. For example, ahigh level person in an organization may have great need for access toconfidential corporate information. The corporation may wish to issuethis person a certificate without any more than a mere request beingfiled. On the other hand, entry level employees at a corporation mayhave very little need for access to confidential information. Thecorporation may wish to have the entry level person's manager approvethe issuance of a certificate. One embodiment of the integrated Accessand Identity System of the present invention incorporates certificatemanagement into the workflow process so different standards forcertificate management can be applied among various entities. In oneimplementation, different certificate enrollment, renewal, andrevocation workflows can be defined for different types of system users.

[0365]FIG. 52 illustrates additional system modules used for supportingcertificate management through the workflow process. Identity Server 40includes certificate registration module 2072, which servicescertificate related requests from system users and administrators.Certificate registration module 2072 carries out workflow processesdefined by administrators to respond to users' requests for certificateenrollment, renewal and revocation. Directory Server 36 maintains a poolof certificates 2082 that are available for issuance to system users.When the system is initialized the administrator applies for a fixednumber of certificates that can be distributed to system users. Issuedcertificates are stored in Directory Server 36 and accessible tocertificate registration module 2072 through Directory Server 36.

[0366] The integrated Access and Identity System of the presentinvention also includes Certificate Processing Server 2076, which is incommunication with Identity Server 40 to communicate with certificateregistration module 2072. Certificate Processing Server 2076 issuescertificate signing requests to Certificate Authority 2084, which isexternal to the integrated Access and Identity System and incommunication with Certificate Processing Server 2076. CertificateAuthority 2084 is typically a third party vendor that providescertificates, including pairs of public and private keys for attachmentto the certificates. One example of a third party certificate provideris Verisign. Certificate Processing Server 2076 is also in communicationwith signing device 2078. Signing device 2078 digitally signscertificate signing requests before they are issued to CertificateAuthority 2084. Digitally signing certificate signing requests heightensthe level of security in the connection between Certificate ProcessingServer 2076 and Certificate Authority 2084. In one embodiment of thepresent invention, certificate registration module 2072 communicateswith Certificate Processing Server 2076 via a secure SSL socketconnection and Certificate Processing Server 2076 communicates withCertificate Authority 2084 via a secure SSL connection to enhance systemsecurity.

[0367]FIG. 53 illustrates the steps performed to respond to a user'scertificate related request in one implementation of the currentinvention. Examples of certificate related requests include enrollment,renewal or revocation request. Identity Server 40 receives thecertificate request (step 2100). Typically the request comes from theuser via Web Server 20. After receiving the request, Identity Server 40responds (step 2102). Certificate registration module 2072 respondsdifferently based upon the type of request operation being requested.The following FIGS. 54-59 illustrate responses of certificateregistration module 2072 to different types of certificate requests,namely requests for enrollment, renewal and revocation.

[0368]FIG. 54 illustrates how certificate registration module 2072responds to a certificate enrollment request in one version of theinvention (step 2102, FIG. 53). Certificate registration module 2072retrieves a certificate enrollment workflow that corresponds to thecharacteristics of the requesting user (step 2120). The workflowcontains a set of directives that must be carried out for responding tothe user's request. In one embodiment, there are multiple certificateenrollment workflows. Each workflow corresponds to a different set ofuser characteristics, such as job title and access privileges.Certificate registration module 2072 selects the enrollment workflowmatching the characteristics of the requesting user.

[0369] Certificate registration module 2072 proceeds with certificateenrollment in accordance with the workflow by retrieving information(step 2122). Examples of the information retrieved include informationfrom the user's identity profile and information from entitiesassociated with the user. Examples of entities associated with therequesting user include the requesting user's manager who also has anidentity profile in the Identity System and can be contacted by IdentityServer 40.

[0370] Certificate registration module 2072 also retrieves approvalresponses, indicating whether issuing a certificate to the requestinguser is allowed (step 2124). For example, certificate registrationmodule 2072, in one implementation, queries a user's manager todetermine whether the user is eligible to receive a certificate. Ifapproval is not granted (step 2126), certificate registration module2072 issues the requesting user a rejection report (step 2130). Ifenrollment is approved (step 2126), certificate registration module 2072obtains a certificate for the user (step 2128). In another embodiment,approval can be based on comparing an LDAP filter to the attributes ofthe user's identity profile.

[0371] In accordance with the present invention, system administratorsare able to define different workflows for different users—making manyvariations of the above-described certificate enrollment processpossible. In alternate implementations, the workflow does not call forretrieving information or obtaining approval responses. Certificateregistration module 2072 immediately moves to obtain a certificate forthe user (step 2128).

[0372]FIG. 55 illustrates operations performed to obtain a certificatefor a requesting user (step 2128, FIG. 54). Certificate registrationmodule 2070 authenticates the requesting user (step 2152). In oneembodiment, authentication is performed by the Access System. Inalternate embodiments, certificate registration module 2072authenticates the user based on challenge information collected duringinformation retrieval (step 2122, FIG. 54). In an alternateimplementation, certification registration module 2072 authenticates theuser from information in the user's cookie. Certificate registrationmodule 2072 forwards a certificate request to Certificate ProcessingServer 2076 (step 2154).

[0373] Certificate Processing Server 2076 obtains a digital signaturefor the request from signing device 2078 (step 2160). CertificateProcessing Server 2076 then forwards the digitally signed request as acertificate signing request to Certificate Authority 2084 (step 2162).Certificate Authority 2084 responds by creating a certificate (step2164) and forwarding the certificate to Certificate Processing Server2076 (step 2166). Certificate Processing Server 2076 forwards thecertificate to certificate registration module 2072 (step 2170).Certificate registration module 2072 stores the new certificate incertificate data store location 2082 (step 2156). Certificateregistration module 2072 then notifies the user that the certificate isin place (step 2158).

[0374] Once a certificate has been issued it is typically valid for apredetermined period of time, such as one year. After the time periodexpires, the certificate holder must renew the certificate. In oneembodiment of the present invention, the certificate holder renews thecertificate by submitting a certificate renewal request to IdentityServer 40. This request is handled by certificate registration module2072 in essentially the same manner as described above for certificateenrollment. The same process is applicable, because the renewal of acertificate is essentially the same as enrollment. When a certificate isrenewed, Certificate Authority 2084 generates a new private key-publickey pair, in essence creating a new certificate without increasing thetotal number of certificates issued to the Identity System. The onlydifference is that Certificate Processing Server 2076 informsCertificate Authority 2084 that a certificate is to be renewed, asopposed to a new certificate being issued.

[0375] When a new certificate is issued through enrollment or acertificate is renewed, the system administrator informs the user thatthe certificate is ready for pick-up. The administrator can send theuser an e-mail indicating the certificate is available on a floppy diskin the administrator's office. The user then goes to the administrator'soffice and picks up the floppy disk with the certificate. The user'scopy of the certificate includes the private key, which is not availablein the certificate maintained in certificate data store 2082. Afterpicking up the certificate, the user installs the certificate in his/herclient device's browser. The copy of the certificate in certificate datastore location 2082 is available for system users to view and obtain thecertificate holder's public key information.

[0376] In an alternate embodiment of the present invention, an automaticrenewal option is provided. In response to an automatic renewal request,renewal is based solely on authenticating the requesting user. No datacollection or additional approval is required. FIG. 56 illustrates oneset of steps taken by certificate registration module 2072 to respond toan automatic renewal request (step 2102, FIG. 53). Certificateregistration module 2072 retrieves the automatic renewal certificateworkflow for the user (step 2190). In one embodiment, there are multipleautomatic renewal workflows with each workflow corresponding to adifferent set of user characteristics. Certificate registration module2072 selects the workflow that matches the characteristics of the user.Certificate registration module 2072 then obtains the renewalcertificate (step 2192).

[0377]FIG. 57 illustrates steps taken to obtain the automatic renewalcertificate (step 2192, FIG. 56). Certificate registration module 2072authenticates the requesting user (step 2212). This authentication canbe performed as explained above for the enrollment process. In anotherimplementation, the user encrypts the request using a private key andcertificate registration module 2072 is able to decrypt the messageusing a corresponding public key. In an alternate embodiment, the userenters a challenge phrase along with the request to provideauthentication.

[0378] Certificate registration module 2072 forwards the automaticrenewal request to Certificate Processing Server 2076 (step 2214).Certificate Processing Server 2076 obtains a digital signature for therequest (step 2220). Certificate Processing Server 2076 forwards therequest to Certificate Authority 2084 as a certificate signing request(step 2222). Certificate Authority 2084 provides a renewalacknowledgement to Certificate Processing Server 2076 (step 2224).Certificate Processing Server 2076 forwards the renewal acknowledgementto certificate registration module 2072 (step 2226). Certificateregistration module 2072 updates the certificate in the data store (step2217) and notifies the user of the certificate renewal (step 2218). Inthe automatic renewal process described above, a new public key-privatekey pair is not issued for the certificate. In alternate embodiments, anew key pair is issued as described with reference to FIG. 55.

[0379]FIG. 58 illustrates steps taken by certificate registration module2076 to respond to a certificate revocation request (step 2102, FIG.53). Certificate registration module 2072 retrieves a certificateworkflow that corresponds to the requesting user for revoking the user'scertificate (step 2250). In one embodiment, there are multiplerevocation workflows with each workflow corresponding to a different setof user characteristics. Certificate registration module 2072 selectsthe revocation workflow matching the requesting user's characteristics.Using the workflow process, certificate registration module 2072 obtainscertificate revocation (step 2252).

[0380]FIG. 59 illustrates steps taken by certificate registration module2072 to obtain certificate revocation (step 2252, FIG. 58). Certificateregistration module 2072 authenticates the requesting user, as describedabove (step 2272). Certificate registration module 2072 forwards thecertificate revocation request to Certificate Processing Server 2076(step 2274). Certificate Processing Server 2076 obtains a digitalsignature for the request from signing device 2078 to form a certificatesigning request (step 2276). Certificate Processing Server 2076 thenforwards the certificate signing request to Certificate Authority 2084(step 2278). Certificate Authority 2284 forwards the revocationacknowledgement to Certificate Processing Server 2076 (step 2080).Certificate Processing Server 2076 then forwards the revocationacknowledgement to certificate registration module 2072 (step 2282).

[0381] The system administrator is responsible for verifying that acertification has been successfully revoked. In one embodiment, thesystem administrator reviews a certificate revocation list provided byCertificate Authority 2084. Certificate Authority 2084 makesarrangements with the system administrator to determine the frequency atwhich the certificate revocation list will be updated. Alternatively,the system administrator employs an Online Certificate Status Protocol(“OCSP”) to check the status of a certificate revocation in real timethrough an online connection with Certificate Authority 2084.° C.SP is areal time protocol provided by Certificate Authority 1084 that enablesapplications to check the status of certificates with the CertificateAuthority. One Certificate Authority that provides such a protocol isVerisign.

[0382] It is important to note that revoking a certificate does notresult in the certificate being deleted from certificate data storelocation 2082. Revoked certificates remain in the data store untilIdentity Server 40 deletes the certificate, which can be done through achange attribute workflow.

[0383] The following table provides example workflows for certificateenrollment, revocation and renewal. TABLE 8 Workflow Actions CertificateEnrollment cert_initiate_enroll provide_info (optional)approval/provide_approval (optional) cert_generate_certificateCertificate Renewal cert_initiate_renew provide_info (optional)approval/provide_approval (optional) cert_generate_certificateCertificate Revocation cert_initiate_revoke cert_revoke_certificate

[0384] The first action in the certificate enrollment workflow iscert_initiate_enroll, which includes certificate registration module2072 presenting the requesting user with a certificate enrollmentpage—indicating that certificate enrollment process is under way. In oneembodiment, the user's browser responds by submitting the certificateenrollment page back to certificate registration module 2072.

[0385] The provide_info action calls for certificate registration module2072 to retrieve information from either the user or an entityaffiliated with the user, as described above. The enrollment workflowcan also contain either an approval action or a provide_approval action.The approval action requires certificate registration module 2072 toobtain approval for certificate issuance from an entity, such as someoneaffiliated with the user. For the provide_approval action, certificateregistration module 2072 obtains information along with the approval.The provide_info, approval, and provide_approval actions are optional.

[0386] The cert_generate_certificate action in the enrollment workflowcauses certificate registration module 2072 to obtain a certificate. Asshown above, certificate registration module 2072 obtains certificateswith the assistance of Certificate Processing Server 2076 andCertificate Authority 2084.

[0387] The actions in the certificate renewal workflow are essentiallythe same as those in the enrollment workflow with the exception ofcert_initiate_enroll being replaced by cert_initiate_renew. Thecert_initiate_renew action causes certificate registration module 2072to present the user with a request to renew button. Certificateregistration module 2072 provides this button when there is apredetermined period of time remaining before an existing certificateexpires. The user requests the renewal of a certificate by selecting thebutton, and certificate registration module 2072 provides the user witha renewal page to be submitted as a renewal request.

[0388] The cert_initiate_revoke action enables certificate registrationmodule 2072 to accept a revocation request. The cert_revoke_certificateaction causes certificate registration module 2072 to carryout therevocation process through Certificate Processing Server 2076 andCertificate Authority 2084.

[0389] As shown above, several of the workflow actions are optional. Theflexibility to add different steps to workflows makes certificatemanagement very flexible. System administrators can create differentcertificate related workflows for different types of users. For example,a particular type of user may be automatically granted a certificateupon requesting enrollment—requiring the workflow to include only thecert_initiate_enroll and cert_generate_certificate actions.Alternatively, another type of user may require approval before acertificate is issued—requiring the workflow to include an approval orprovide_approval action. In further embodiments, system administratorscan also initiate certificate related requests on behalf of systemusers.

[0390] As described above, Identity Server 40 maintains public copies ofcertificates in certificate data store location 2082. Identity Systemusers issue requests to Identity Server 40 to export or display thecertificates. In one embodiment of the present invention, the IdentitySystem maintains real time status information about the certificates, sousers are not unknowingly importing or viewing expired certificates.Maintaining this status information is beneficial, because certificatestatus is a dynamic value that cannot typically be provided in acertificate field.

[0391]FIG. 59A shows a sequence of steps performed by Identity Server 40to obtain and maintain real time certificate status in oneimplementation of the present invention. Identity Sever 40 retrievesreal time status for a certificate (step 3400). Identity Server 40retrieves the status from Certificate Authority 2084 using a real timeprotocol. One example of a real time protocol is the well known OCSPprotocol identified above. The retrieved status indicates whether thecertificate is valid, expired, or revoked. In one implementation,Identity Server 40 retrieves certificate status directly fromCertificate Authority 2084. In an alternate implementation, IdentityServer 40 retrieves certificate status from Certificate Authority 2084through Certificate Processing Server 2076.

[0392] Identity Server 40 stores the retrieved certificate status inDirectory Server 36 (step 3402). Identity Server 40 also storesvalidation information for the certificate in Directory Server 36 (step3404). In one implementation, the validation information includes: 1)Status Retrieval Time -indicating the time that Identity Server 40retrieved the certificate's real time status in step 3400 and 2)Validation Interval-indicating a time period extending from the StatusRetrieval Time. In one embodiment of the present invention, theValidation Interval is set to a value of zero, if the certificate'sstatus is not valid.

[0393] In one embodiment, Identity Server 40 performs the sequence ofsteps shown in FIG. 59A in response to a request from a user or systemadministrator that identifies a certificate. In alternate embodiments,Identity Server 40 also automatically carries out the steps in FIG. 59Aat predetermined time intervals.

[0394]FIG. 59B illustrates a sequence of steps carried out by IdentityServer 40 to export a certificate in one version of the presentinvention. Identity Server 40 receives a user request via Web Server 20to export a certificate from certificate data store location 2082 (step3420). Identity Server 40 determines whether to check the status of therequested certificate (step 3422). In one implementation, IdentityServer 40 makes this determination by querying a parameter field in theIdentity System. This parameter field can be set by a systemadministrator during system configuration.

[0395] If a status check is not required, Identity Server 40 exports therequested certificate to the user via Web Server 20 (step 3434).Otherwise, Identity Server 40 determines whether a real time statuscheck of the certificate is required (step 3424). Identity Server 40also makes this determination in one embodiment by querying an IdentitySystem parameter field. If a real time status check is required,Identity System 40 retrieves the requested certificate's real timestatus from Certificate Authority 2084, as described above withreference to FIG. 59A. In some embodiments, Identity Server 40 alsostores the retrieved real time certificate status and related validationinformation as shown in FIG. 59A. Identity Server 40 determines whetherthe certificate's real time status is valid (step 3430). If the statusis valid, Identity Server 40 exports the certificate (step 3434).Otherwise, Identity Server 40 issues an error message to the user (step3432).

[0396] If real time status checking was not required (step 3424),Identity Server 40 determines whether the user's export request fallswithin the Validation Interval for the certificate (step 3428). Asexplained above, the Validation Interval is a window of time extendingfrom the last time the certificate's real time status was retrieved. Inone embodiment, the Validation Interval is one hour. In variousembodiments, the Validation Interval has many different values. As theValidation Interval is reduced, the probability increases that thestored real time status for the certificate is still accurate. If theexport request falls within the Validation Interval, Identity Server 40exports the requested certificate (step 3434). Otherwise, IdentityServer 40 issues an error message to the user (step 3432). By employingstored real time certificate status, Identity System 40 can supply realtime status for large numbers of certificates. In one embodiment, theValidation Interval is zero for a certificate that is notvalid-resulting in Identity Server 40 issuing an error message inresponse to the determination in step 3428.

[0397]FIG. 59C illustrates a sequence of steps executed by IdentityServer 40 to display certificate information in one embodiment of thepresent invention. Identity Server 40 receives a user request via WebServer 20 to display a certificate in data store location 2082 (step3450). Identity Server 40 determines whether certificate status is to bedisplayed along with the certificate (step 3452). In one implementation,Identity Server 40 makes this determination by querying a parameterfield in the Identity System set by the Identity System administrator.

[0398] If certificate status is not required (step 3452), IdentityServer 40 identifies the fields in the requested certificate that are tobe displayed (step 3460). Identity Server 40 identifies these fields inone embodiment by querying a set of parameters in the Identity Systemthat are programmed by the Identity System administrator. IdentitySystem 40 then displays the identified fields from the certificatewithout any certificate status (step 3466).

[0399] If certificate status is required (step 3452), Identity Server 40determines whether a real time certificate status check is required(step 3454). Identity Server 40 makes this determination in oneimplementation by querying an Identity System parameter field. If a realtime status check is required, Identity Server 40 retrieves a new realtime status for the certificate (step 3456), as described above withreference to FIG. 59A. In some implementations, Identity Server 40 alsostores the status and validation information as shown in FIG. 59A. If areal time status check is not required (step 3454), Identity Server 40retrieves previously obtained real time status that is stored in theIdentity System for the certificate (step 3458).

[0400] Identity Server 40 identifies the fields in the requestedcertificate that are to be displayed after obtaining certificate statusin real time or from storage (step 3462). Identity Server 40 thendisplays the identified fields for the certificate and the certificate'sstatus (step 3464).

[0401] The operations described above in FIGS. 59A-59C can also beemployed to provide users with dynamic certificate related informationother than certificate status. Examples of other dynamic informationinclude certificate policies and certificate costs.

[0402] The discussions above regarding workflows, groups, communicationbetween Identity Servers, etc., primarily pertain to managing and usingthe Identity System. As stated above, the Identity System managesidentity profiles. These identity profiles are used, among other things,to authenticate users and to authorize users to access resources. TheAccess System has primary responsibility for providing authenticationand authorization services. In one embodiment, authentication andauthorization services are performed based on using identity profileswith authentication and authorization rules. These authentication andauthorization rules are associated with policy domains and policies, asdescribed above.

[0403]FIG. 60 is a flow chart, which describes the process of creating apolicy domain. In step 2400, the Access System receives a request tocreate a policy domain. In step 2402, the name of the policy domain andthe description of the policy name are stored. In step 2404, one or moreURL prefixes are added to the policy domain. In step 2405, one or morehost ID's are added to the policy domain (optional). Next, one or moreaccess rules are added to the policy domain (steps 2406 and 2408). Anaccess rule is a rule about accessing a resource. Examples of accessrules include authorization rules, authentication rules, auditing rules,and other rules, which are used during the process of attempting toaccess a resource.

[0404] In step 2406, a first level (default) authentication rule isadded to the policy domain. In general, authentication is the process ofverifying the identity of the user. Authentication rules specify thechallenge method by which end users requesting access to a resource inthe policy domain must prove their identity (authentication). Aspreviously discussed, first level (default) authentication rules applyto all resources in a policy domain, while second level authenticationrules are associated with policies that apply to subsets of resources orspecific resources in the policy domain. In one embodiment, there isonly one default authentication rule for a policy domain. If anadministrator desires an authentication rule to apply to only a specificresource in the policy domain, a separate policy for that specificresource having a second level (specific) authentication rule should bedefined.

[0405] After setting up the authentication rule in step 2406, one ormore first level or default authorization rules are added to the policydomain in step 2408. In general, an authorization rule determines whocan access a resource. The default authorization rule allows or deniesusers access to resources within its applicable policy domain. Ifmultiple authorization rules are created, then they are evaluated in anorder specified in step 2410. In step 2412, a first level (default)audit rule is configured for the policy domain. In step 2414, zero ormore policies are added to the policy domain. In step 2416, the data forthe policy domain is stored in Directory Server 36 and appropriatecaches (optional) are updated. In one embodiment, an authorization ruleor an authentication rule can be set up to take no action. That is,always grant authentication without any challenge or verification; oralways grant authorization without any verification.

[0406]FIG. 61 is a flow chart describing the process of adding one ormore authorization rules to a policy domain. In step 2432, timingconditions are set up for the authorization rule. Timing conditionsrestrict the time when the authorization rule is in effect. For example,users can be allowed access to URLs in the policy domain only duringbusiness hours, Monday through Friday. In one embodiment, if timingconditions are not set, the authorization rule is always in effect. Thetiming conditions for establishing the time a rule is valid include: (1)selecting a start date and an end date, (2) selecting a start time andan end time, (3) selecting the months of the year, (4) selecting thedays of the month, and (5) selecting days of the week.

[0407] In steps 2434 and 2436, authorization actions are set up.Authorization actions personalize the end user's interaction with theWeb Server. In step 2434, header variables are provided forauthorization success events and authorization failure events. Thisfeature allows for the passing of header variables about the end user(or other information) to other web-enabled resources. Web-enabledapplications can personalize the end user's interaction with the WebServer using these header variables. As a simple example, the actionscould supply each application with the user's name. An application couldthen greet the user with the message “hello <user's name>” whenever theuser logs on. Header variables are variables that are part of an HTTPrequest. If an authorization rule is set up with header variables aspart of an authorization success action, a successful authorizationcauses the HTTP request to the resource to include the header variables.Similarly, if there are header variables for an authorization failure,an authorization failure event includes adding header variables to theHTTP request that redirects a browser to an authorization failure webpage. The resources identified by the HTTP requests that include theheader variables can use the header variables any way desired. In oneembodiment of the method of FIG. 61, one or more groups can be specifiedfor authorization to the resource(s).

[0408]FIG. 62 is a flow chart that describes the process of addingheader variables to an HTTP request. Header variables can be addedduring an authorization success event, authorization failure event,authentication success event or authentication failure event. In step2450, the variable name is entered. In step 2452, a text string isentered. In step 2454, one or more LDAP attributes are entered. In step2456, it is determined whether any more header variables will be added.If not, the method of FIG. 62 is done (step 2458). If so, the method ofFIG. 62 loops back to step 2450.

[0409] The variable name entered in step 2450 is a value that appears inthe HTTP header to name the variable. The downstream resource using theheader variable searches for the variable name. The string entered isdata that can be used by the downstream resource. The LDAP attribute(s)can be one or more attributes from the requesting user's identityprofile. Thus, the following can occur in the simple authorizationsuccess example described above: (1) the variable name field can include“authorization success,” (2) the return field can include “yes,” and (3)the attribute field can include the name attribute for the user in theuser's identity profile. Any of the attributes from the user's identityprofile can be selected as a header variable.

[0410] Looking back at FIG. 61, in step 2436, a redirect URL can beadded for an authorization success event and a redirect URL can beentered for an authorization failure event. Step 2438 includesspecifying the users allowed to access the resource associated with theauthorization rule. By default, users cannot access a resource untilthey are granted access rights. In one embodiment, there are at leastfour means for specifying who can access a resource. The first means isto explicitly name a set of users who can access the resource. A secondmeans includes identifying user roles. The third means is to enter anLDAP rule that can be used to identify a set of users based on acombination of one or more attributes. A fourth means is to enter an IPaddress, which allows users of computers having the specified IP addressto access the resource.

[0411] Step 2440 is used to specify the users not allowed to access theresource associated with this rule. Identification of users, roles, LDAPrules, and IP addresses are entered in step 2440 in the same manner asentered in step 2438. It is possible that a particular user can besubject to both an allow access rule and a deny access rule. Step 2442is used to set a priority between such rules. Optional step 2444 is usedto define any POST data to be used for authorization if this feature isimplemented. An HTTP POST request can include POST data in the body ofthe HTTP request. POST data can also be submitted in query string form.One embodiment of the present invention allows POST data to be used forauthorization purposes.

[0412] In optional step 2444, an administrator defines which POST datais to be used for authorization purposes. If POST data is to be used forauthorization to satisfy an authorization rule, the POST request mustinclude all the appropriate POST data and values for that POST data asdefined in step 2444. However, it will be understood that POST data neednot be used for authorization in all embodiments of the presentinvention. Step 2446 is used to set a priority of evaluation for theauthorization rule relative to other authorization rules in a givenpolicy. In one embodiment, if multiple authorization rules apply to aresource, this priority determines the order of evaluation.

[0413]FIG. 63 is a flow chart describing the process for adding anauthentication rule. In step 2470, a challenge scheme (also called anauthentication scheme) is selected. An authentication scheme is a methodfor requesting log-on information (e.g. name and password) from endusers trying to access a web resource. Within an authentication schemeis a challenge method (e.g. Basic, certificate or form). There can bemore than one authentication scheme with the same challenge method (e.g.Basic over LDAP, Basic over NT Domain, . . .). Various otherauthentication schemes can also be used. In step 2472, header variablesare added for authentication success and authentication failure events.In step 2474, redirect URLs are added for authentication success eventsand authentication failure events.

[0414]FIG. 64 is a flow chart describing the process of adding a policy.In step 2518, a resource type is specified. The resource type allowsdifferent resources to be handled by different policies, depending onthe nature of the resource itself. For example, in one embodiment, theresource type will distinguish between resources accessed using HTTP andresources accessed using FTP. In one embodiment, Enterprise Java Beans(EJBs) are a possible resource type. In another embodiment, user-definedcustom resource types are supported. In step 2520, an operation type isspecified. This allows different resources to be handled by differentpolicies, depending on the operations used to request the resource. Inone embodiment, the operations will be HTTP requests. Supported HTTPrequest methods include GET, POST, PUT, HEAD, DELETE, TRACE, OPTIONS,CONNECT, and OTHER. In another embodiment, if EJBs are identified as theresource type, an EXECUTE operation can be specified in step 2520. Inanother embodiment, user-defined custom operations are supported. Otherand future operations can also be supported.

[0415] In step 2522, a pattern for the URL path (or other type of path)to which the policy applies is specified. This is the part of URL thatdoes not include the scheme (“http”) and host/domain (“www.oblix.com”),and appears before a ‘?’ character in the URL. In step 2524, a querystring is specified. This is a set of variables and values that must beincluded in the specified order in an incoming URL for the policy tomatch and be activated. For example, in the URL

[0416] “HTTP://www.zoo.com/animals.cgi?uid=maneaters&tigers=2”

[0417] the values after the question mark (e.g.“uid=maneaters&tigers=2”) comprise a query string. Only a URL exhibitingthe query string can match to this policy. For example, a URL with the“tigers” variable appearing before the “uid” variable will not match theabove-identified policy.

[0418] In step 2526, query string variables are added. Query stringvariables include a name of a variable and the variable's correspondingvalue. Query string variables are used when it is desirable for multiplevariables to be found in the query string, but the order is unimportant.Thus, for a policy with query string variables “uid=maneaters” and“tigers=2,” a URL with a query string having the appropriate uid andappropriate tigers variable, in any order, will match the policy. Inorder for a resource URL to apply to a policy, the path of the requestedresource URL must match the path of the policy as well as any querystring or query variables. As discussed above, POST data can besubmitted in query string form (for example, in a form submission), andevaluated using the query string variables entered in step 2526.

[0419] The query string or query variables specified in the steps ofFIG. 64 do not need to uniquely identify a resource. Rather, they areused to identify a policy, which may apply to one or more resources.

[0420] Typically, the query data is added to a URL to access certaindata from a resource. However, the query data can be used in the URL toidentify the resource. Each application or resource is free to use thequery data in any way that is in agreement with standards and normsknown in the art.

[0421] In step 2528 of FIG. 64, the authentication rule is created inaccordance with the method of FIG. 63. In step 2530, one or moreauthorization rules are created for the policy in accordance with themethod of FIG. 61. In step 2532, an audit rule for the policy isconfigured. In step 2534, POST data (optional) is added to the policy.This POST data is used to map resources with policies.

[0422] The present invention supports the use of multiple authenticationschemes. An authentication scheme comprises an authentication level, achallenge method, an SSL assertion parameter, a challenge redirectparameter, and authentication plug-ins. The authentication levelrepresents an arbitrary designation of the level of confidence that anadministrator has in a particular authentication scheme relative toother authentication schemes.

[0423] In one embodiment of the present invention, an authenticationscheme can specify one of four challenge methods: none, basic, form, andX.509. If an authentication scheme's challenge method is set to “none,”no authentication is required to access a requested resource, thusallowing support for unauthenticated users. This challenge method can beused over both unsecured as well as SSL connections. The “basic”challenge method can also be used over both unsecured and SSLconnections. The “X.509” challenge method can be used over an SSLconnection between a user's browser and Web Server host. A “form”challenge method employs a custom, site-specific HTML form presented tothe user, who enters information and submits the form. Subsequentprocessing is determined by the administrator at the time theauthentication scheme is created. Form challenge methods can be usedover both unsecured and SSL connections.

[0424] The SSL parameter of an authentication scheme identifies whetherSSL is to be asserted on the connection to the user's browser by the WebServer. The challenge parameter identifies where to redirect a requestfor authentication for the particular authentication scheme.Authentication plug-ins are necessary for processing the user's suppliedinformation. Authentication plug-ins can interface with Access Server 34through an authentication API.

[0425] An authentication scheme that an attacker can easily andprofitability eavesdrop upon is typically considered “weak.” In oneembodiment, the basic authentication challenge method places the user'scredential (supplied information), a simple password, “in the clear”over an unsecured network connection. However, the authentication schemecan be made stronger by passing the user's credential over an encryptedconnection, such as SSL. In one embodiment, given two authenticationschemes (one with and one without SSL), an access administrator willassign the authentication scheme without SSL to a lower authenticationlevel than the authentication using SSL.

[0426] When a user first requests a protected resource, the user ischallenged according to either: (1) the authentication scheme defined bythe first level authentication rule in the applicable policy domain, or(2) the second level authentication rule in the applicable policyassociated with the requested resource. If the user satisfies theauthentication rule, an encrypted authentication cookie is passed to theuser's browser indicating a successful authentication. Onceauthenticated, the user may request a second resource protected by adifferent policy domain and/or policy with a different authenticationrule. The user is allowed access to the second resource withoutre-authenticating under the following condition: the authenticationlevel of the authentication scheme used to successfully authenticate forthe first resource is equal to or greater than the authentication levelof the authentication scheme of the second resource. Otherwise, the useris challenged and asked to re-authenticate for the second resource inaccordance with the second resource's higher level authenticationscheme. Satisfaction of a higher or lower authentication level isdetermined by evaluating the authentication cookie sent by the user'sbrowser when requesting the second resource. In one embodiment of thepresent invention, administrators can define an unlimited number ofauthentication levels.

[0427] Once authenticated, a user can explicitly log out, causingauthentication cookies cached (or otherwise stored) by the user'sbrowser to be destroyed or become invalid. Authentication cookies canalso be set by an administrator to be destroyed after a maximum idletime has elapsed between requests to resources protected in accordancewith the present invention.

[0428]FIG. 65 provides a flow chart for one embodiment of a method forauthenticating, authorizing, and logging. In step 2550, a user's browser12 requests a web-enabled resource 22 or 24. The request is interceptedby Web Gate 28 in step 2552. The method then determines whether therequested resource is protected by an authentication and/orauthorization rule in step 2553. If the resource is not protected, thenaccess is granted to the requested resource in step 2595. If therequested resource is protected, however, the method proceeds to step2554. If the user has previously authenticated for a protected resourcein the same domain, a valid authentication cookie is passed by browser12 with the request in step 2550. The authentication cookie isintercepted by Web Gate in step 2552. If a valid cookie is received(step 2554), the method attempts to authorize the user in step 2556. Ifno valid authentication cookie is received (step 2554), the methodattempts to authenticate the user for the requested resource (step2560).

[0429] If the user successfully authenticates for the requested resource(step 2562), then the method proceeds to step 2574. Otherwise, theunsuccessful authentication is logged in step 2564. After step 2564, thesystem then performs authentication failure actions and Web Gate 28denies the user access to the requested resource in step 2566. In step2574, the successful authentication of the user for the resource islogged. The method then performs authentication success actions in step2576. In response to the successful authentication, Web Gate 28 thenpasses a valid authentication cookie to browser 12 (step 2580), whichstores the cookie. After passing the cookie in step 2580, the systemattempts to authorize in step 2556.

[0430] In step 2556, the method determines whether the user isauthorized to access the requested resource. If the user is authorized(step 2590), the method proceeds to step 2592. Otherwise, theunsuccessful authorization is logged in step 2596. After step 2596, themethod performs authorization failure actions (step 2598) and Web Gate28 denies the user access to the requested resource. If authorization issuccessful (step 2590), then the successful authorization of the user islogged in step 2592. Authorization success actions are performed in step2594. The user is granted access to the requested resource in step 2595.In one embodiment of step 2595, some or all of HTTP request informationis provided to the resource. In one or more scenarios, the resourcebeing accessed is the Identity System.

[0431]FIG. 66 provides a flow chart of a method for determining whethera requested resource is protected. In step 2630, Web Gate 28 determineswhether an entry for the requested resource is found in a resourcecache. If an entry is found, the cache entry is examined in step 2642 todetermine whether the cache entry indicates that the resource isprotected (step 2632) or unprotected (step 2640). If an entry for therequested resource is not found in the resource cache, then Web Gate 28passes the URL of the requested resource request method to Access Server34 in step 2633. Access Server 34 attempts to map the requested resourceto a policy domain (step 2636).

[0432] If mapping step 2636 is unsuccessful (step 2638), then therequested resource is deemed to be unprotected (step 2640). However, ifa successful mapping has occurred (step 2638), then Access Server 34retrieves the authentication rule (step 2644) and audit rule (step 2646)associated with the requested resource. Access Server 34 then passes theauthentication scheme ID from the authentication rule, audit mask, andany POST data received to Web Gate 28 in step 2648. Web Gate 28 cachesthe authentication scheme ID from the authentication rule, audit mask,and POST data in the resource cache (step 2650). Since the requestedresource was successfully mapped to a policy domain in step 2636, theresource is deemed protected (step 2632).

[0433]FIG. 67 is a flow chart describing the process for mapping aresource to a policy domain. In step 2700, Access Server 34 receives theURL of the requested resource from Web Gate 28. Access Server 34 thencompares a URL prefix of the requested resource with entries in a URLprefix cache in step 2702. In one embodiment, when step 2702 is calledfor the first time, the URL prefix of the requested resource equals thefile name. Thus, if the URL of the requested resource reads:“http://www.oblix.com/oblix/sales/index.html” then the URL prefix firstcompared by step 2702 will be: “/oblix/sales/index.html.” If a matchingURL prefix is found (step 2704), Access Server 34 proceeds to step 2716.

[0434] In step 2716, Access Server 34 determines whether the policydomain associated with the matching URL prefix calls for one or morehost ID's. In one embodiment, resources are mapped to certain policydomains if the port number of a resource request and the location of theresource itself conform to one or more host ID's. Thus, multiple policydomains can be associated with identical URL prefixes, each policydomain requiring different host ID's (or none at all). If the policydomain considered in step 2716 requires a matching host ID, then AccessServer 34 proceeds to step 2717. Otherwise, Access Server 34 proceedsdirectly to step 2706 where the requested resource is mapped to thepolicy domain associated with the currently considered URL prefix. Instep 2717, if a matching host ID is found, Access Server 34 proceeds tostep 2706. If no matching host ID is found, Access Server 34 returns tostep 2704 where it determines whether additional matching URL prefixesexist.

[0435] If no matching URL prefix is found in step 2704, then AccessServer 34 proceeds to step 2708. In step 2708, Access Server 34 cropsthe right-most term from the resource URL prefix compared in step 2702.Thus, if the resource URL prefix compared in step 2702 reads:“/oblix/sales/index.html” then the resource URL prefix will be croppedin step 2708 to read: “/oblix/sales.” If the entire resource URL prefixhas been cropped in step 2708 such that no additional terms remain (step2710), then the method proceeds to step 2712 where Access Server 34concludes that there is no policy domain associated with the requestedresource. However, if one or more additional terms remain in theresource URL prefix, then the method returns to step 2702 where thecropped URL prefix is compared with URL prefixes cached in the URLprefix cache.

[0436] As will be apparent from FIG. 67, the method recursively performssteps 2702, 2704, 2708, and 2710 until either a match is found (step2704) or the entire resource URL prefix has been cropped (step 2710). Inany case, the method of FIG. 67 will inevitably return either asuccessful mapping (step 2706) or no mapping (step 2712).

[0437]FIG. 68 provides a flow chart describing a method for loading anauthentication rule. In step 2730, Access Server 34 loads the firstlevel (default) authentication rule for the policy domain mapped in step2636 of FIG. 66 from Directory Server 36 into an authentication rulecache. In one embodiment, success and failure actions are part ofauthentication and authorization rules. In this step, Access Server 34also builds an array of all second level rules and patterns associatedwith each of the policies for the policy domain. Access Server 34 thenselects a second level rule in the array (step 2731). The selectedsecond level rule is part of a policy. In step 2732, Access Server 34performs a pattern matching method for determining whether the ruleapplies to the requested resource. If so, then Access Server 34 proceedsto step 2735; otherwise, Access Server 34 determines whether all rulesin the array have been evaluated (step 2733). If, in step 2733, it isdetermined that not all of the rules in the array have been evaluated,then Access Server 34 selects the next rule in the array (step 2734) andreturns to step 2732. Once all rules in the array have been considered(step 2733), the first level authentication rule previously loaded instep 2730 is returned as the authentication rule. No second levelauthentication rule is loaded into authentication rule cache, and themethod of FIG. 68 is done (step 2737). If an associated policy was foundin step 2732, then the system caches the second level authenticationrule, and success and failure actions for the rule in the authenticationrule cache (step 2735), returns that second level authentication rule(step 2736), and the method is done (step 2737).

[0438]FIG. 69 is a flow chart describing a method for determiningwhether a policy is associated with a resource. A policy URL can containthe following three types of patterns:

[0439] 1. Pattern on the path of the URL: This is the part of URL thatdoes not include the scheme (“http”) and host/domain (“www.oblix.com”),and appears before a ‘?’ character in the URL. In the example URL:

[0440]http://www.oblix.com/oblix/sales/index.html?user=J.Smith&dept=engg

[0441] the absolute path is “/oblix/sales/index.html.”

[0442] 2. Pattern on name value pairs in the URL: This may be a set ofpatterns. They apply to query data (data appearing after the ‘?’character in the URL when operation is GET, or the POST data ifoperation is POST) and are configured as name (no pattern allowed) plusa pattern or value. For example: variable name pattern user *Smith dept*sales*

[0443] If multiple name value pairs are specified, they all must matchto the incoming resource URL. So the URL:

[0444]http://www.oblix.com/oblix/sales/index.html?user=J.Smith&dept=engg

[0445] will not match this pattern set. This pattern does not include anotion of order to these name-value pairs. A URL:

[0446]http://www.oblix.com/oblix/sales/index.html?dept=sales&user=J.Smith

[0447] (with reverse order of “dept” and “user”) will also satisfy thispattern. This is important because it is usually difficult to controlthe order of name value pairs in GET/ POST query data.

[0448] 3. Pattern on the entire query string: This is useful when anadministrator desires to enforce an order on the query string. Forexample, a pattern “user=*Smith*sales” will match query string“user-J.Smith&dept=sales.”

[0449] A policy can contain one or more of above types of patterns. Ifmultiple patterns are specified in one policy, they ALL must match tothe incoming resource URL. If not, that policy doesn't apply to theincoming resource URL.

[0450] Patterns used for one embodiment of the current invention can usethe following special characters:

[0451] 1. ?: Matches any one character other than ‘/’. For example,“a?b” matches “aab” and “azb” but not “a/b.”

[0452] 2. *: Matches any sequence of zero or more characters. Does notmatch ‘/’. For example, “a*b” matches “ab,” “azb,” and “azzzzzzb but not“a/b.”

[0453] 3. [“set”]: Matches one from a set of characters. “set” can bespecified as a series of literal characters or as a range of characters.A range of characters is any two characters (including ‘-’) with a ‘-’between them. ‘/’ is not a valid character to include in a set. A set ofcharacters will not match ‘/’ even if a range which includes ‘/’ isspecified. Examples includes: “[nd]” matches only “n” or “d”; “[m-x]”matches any character between “m” and “x” inclusive; “[—b]” matches anycharacter between “-” and “b” inclusive (except for “/”); “[abf-n]”matches “a,” “b,” and any character between “f” and “n” inclusive; and“[a-f-n]” matches any character between “a” and “f” inclusive, “-,” or“n.” The second “-” is interpreted literally because the “f” precedingit is already part of a range.

[0454] 4. {“pattern1,”“pattern2”, . . . }: Matches one from a set ofpatterns. The patterns inside the braces may themselves include anyother special characters except for braces (sets of patterns may not benested). Examples includes: “a{ab,bc}b” matches “aabb” and “abcb”;“a{x*y,y?x}b” matches “axyb,” “axabayb,” “ayaxb,” etc.

[0455] 5. “/. . . /”: Matches any sequence of one or more charactersthat starts and ends with the ‘/’ character. Examples includes: “/ . . ./index.html” matches “/index.html,” “/oblix/index.html,” and“/oblix/sales/index.html,” but not “index.html,” “xyzindex.html,” or“xyz/index.html”; and “/oblix/ . . . /*.html ” matches“/oblix/index.html,” “/oblix/sales/order.html,” etc.

[0456] 6. “\”: Any character preceded by a backslash matches itself.Backslash is used to turn off special treatment of special characters.Examples include “abc\d” only matches “abc*d”; and “abc\\d” only matches“abc\d.”

[0457] To increase the speed of pattern matching, the system tries to dosome work up front. When Access Server 34 loads a pattern, it creates anobject. This object's constructor “compiles” the pattern. This compilingis essentially building a simple state machine from one pattern toother, i.e., it creates a chain of “glob nodes.” Each glob node consistsof either one pattern or a node set. For example, consider pattern: / .. . /abc*pqr{uv,xy*}.

[0458] The chain would look like:

[0459] node(“/ . . . →node(“abc”)→node(“*”)→

[0460] node(“pqr”)→nodeset(node(“uv”), (node(“xy”)→

[0461] node(“*”)))

[0462] Once the chain is constructed, it is used to match a resource URLto the pattern. Each node or node set in this chain takes a pointer to astring, walks it and decides if it matches the pattern held by the node.In doing so, it also moves this pointer further up in the string. Forexample, when the system gets a URL “/1/3/abcdepqrxyz,” the system takesthis string and starts walking the chain. Below is an example ofevaluation at each node/ node set and pointer (*p) in the string. Notethat the original string is not modified. To begin with lets assume thatthe pointer points to the beginning of the string: *p“/1/3/abcdepqrxyz.”:

[0463] Step 1: node(“/ . . . /”)→MATCHES→advance *p→abcdepqrxyz.”

[0464] Step 2: node(“abc”)→MATCHES→advance *p →depqrxyz.”

[0465] Step 3: node(“*”)→* matches everything except special characters( unescaped ‘?,’ ‘*’,‘[,’ ‘],’ ‘{,’ ‘},’ ‘/’), so at this point, thesystem tries matching to the next node, node(“pqr”) like this:

[0466] a) does *p→“depqrxyz” match node (“pqr”)? NO, advance*p→“epqrxyz.”

[0467] b) does *p→“epqrxyz” match node (“pqr”)? NO, advance *p→“pqrxyz.”

[0468] c) does *p→“pqrxyz” match node (“pqr”)? YES, advance *p→“xyz.” Ifwe walked to the end of string and didn't find a “pqr” (for example incase of URL “/1/3/abcdefgh” ) there is no match.

[0469] Step 4: nodeset(node(“uv”), (node(“xy”)→node(“*”))): A nodesetwill match an incoming string (in the example, *p→“xyz” ) to one of theset members. In this case “xyz” does not match “uv,” but it does match“xy*.” So there is a MATCH and *p→‘\0.’

[0470] Step 5: The pointer is at the end of the string. So the match issuccessful.

[0471] At any point, if the system finds a node that does not match itsstring, the system stops processing and concludes that the string doesnot match the pattern. For example, a URL “/1/3/dddddd” will clear step1 above, but will fail step 2, so the matching stops after step 2.

[0472] Referring to FIG. 69, in step 2740, Access Server 34 retrievesthe policy information from a policy domain cache, which cache's datafrom the directory server. The policy information can include one ormore of the following: a URL absolute path, a query string, and zero ormore query variables. In step 2741, Access Server 34 determines whetherthe requested resource matches the policy resource type. If the resourcetype does not match, Access Server 34 skips to step 2752. However, ifthe resource type does match, Access Server 34 proceeds to step 2742. Instep 2742, Access Server 34 determines whether the operation used torequest the resource matches a policy operation type. If the operationtype does not match, Access Server 34 skips to step 2752. If theoperation type does match, Access Server 34 proceeds to step 2743.

[0473] In step 2743, the policy URL absolute path, query variables, andquery strings are broken up into various nodes, as described above. Instep 2744, the various nodes are stored. Access Server 34 accesses therequested resource URL in step 2746. In step 2748, the first node of thepolicy URL is considered by Access Server 34. In step 2750, AccessServer 34 considers whether the considered node matches the resourceURL, as described above. If the first node does not match, then theentire policy will not match (step 2752). If the node does match theresource URL, or if there is no nodes for the policy, then in step 2754it is determined whether there are any more nodes to consider. If morenodes remain to be considered, then in step 2756 the next node isconsidered and the method loops back to step 2750. If there are no morenodes (step 2754), the query string for the policy is compared to thequery string of the resource URL in step 2758. If the query string forthe policy exactly matches the query string for the resource URL, or ifthere is no query string for the policy, then the method continues withstep 2760. If the query string for the policy does not match the querystring for the resource URL, then the resource URL does not match and isnot associated with the policy (step 2752).

[0474] In step 2760, it is determined whether there are any queryvariables to consider that have not already been considered. If thereare query variables to consider, then the next query variable isaccessed in step 2764. The accessed query variable is searched for inthe resource URL in step 2765. If the query variable is found in theresource URL and the value for the query variable matches the storedvalue query variable in for the policy (step 2766), then the methodcontinues at step 2760; otherwise, Access Server 34 proceeds to step2767. The purpose of steps 2760, 2764, 2765, and 2766 is to determinewhether each of the query variables (and associated values) defined fora policy are found, in any order, in the resource URL. If all of thequery variables are in the URL with the appropriate values, than thereis a match (step 2770). In one embodiment, the query string and thequery variables are in the portion of the URL following the questionmark.

[0475] If, in step 2766, a match is not found, then it is determinedwhether a match may still be possible using POST data. In oneembodiment, resources are mapped to policies by matching POST datasubmitted with resource requests. Thus, different policies can beassociated with a given resource, depending on the contents of the POSTdata. For example, a user may request a resource during the course ofsubmitting an online form containing POST data. Applicable policies canbe mapped on the basis of POST data added to the policy. In step 2767,Access Server 34 determines whether the policy operation type is an HTTPPOST request. If not, then there is no match (step 2752). However, ifthe operation type is an HTTP POST request, then Access Server 34proceeds to step 2768 where Access Server 34 requests and receives thePOST data from Web Gate 28. In one embodiment, Web Gate 28 transmits aflag with all POST requests forwarded to Access Server 34. When POSTdata is transmitted with an HTTP POST request, the flag is set. If noPOST data is transmitted, then the flag is not set. In step 2769, AccessServer 34 evaluates whether the POST data received in step 2768 matchesthe POST data required by the policy to achieve a match. If the POSTdata matches, then the method proceeds to step 2770. Otherwise, themethod proceeds to step 2752.

[0476] An Internet domain can reside on a single Web Server, or bedistributed across multiple Web Servers. In addition, multiple Internetdomains can reside on a single Web Server, or can be distributed acrossmultiple Web Servers. In accordance with the present invention, theAccess System allows a user to satisfy the authentication requirementsof a plurality of domains and/or Web Servers by performing a singleauthentication.

[0477] In the simplest case, all of an e-business host company's WebServers will be in the same domain (i.e. oblix.com). When a usersuccessfully authenticates at one of the Web Servers, the Web Gaterunning on the authenticating Web Server causes the Web Server to returnan encrypted cookie, indicating a successful authentication. Subsequentrequests by the browser to the domain will pass this cookie (assumingthe cookie applies to the requested URL), proving the user's identity;therefore, further authentications are unnecessary.

[0478] In a more complex case, an e-business host company's web presenceincorporates associated web sites whose Web Servers have names inmultiple domains. In such a multiple domain case, each of the associatedportal Web Servers use a Web Gate plug-in configured to redirect userauthentication exchanges to the e-business host's designated web log-inWeb Server. The user is then authenticated at the e-business host's weblog-in server, and an encrypted cookie is issued for the e-businesshost's domain to the user's browser. The user's browser is thenredirected back to the original associated portal's site where the WebGate creates a new cookie for the associated portal's domain and returnsit to the user's browser.

[0479] As a result, the user is transparently authenticated in both theoriginal associated portal's domain and the e-business host's domain.The process is transparently performed for each different associatedportal that a user may visit during a session. The present invention'sassociated portal support easily supports single Web Servers havingmultiple DNS names in multiple domains, and/or multiple networkaddresses. In accordance with the present invention, this multipledomain authentication enables “staging” of web sites. For example, a newedition of a web site can be deployed on a separate set of servers, andthen mapped to policy domains protected by the present invention bysimply updating the policy domain's host ID's.

[0480]FIG. 70 provides a flow chart of one embodiment of a method forauthenticating. In step 2920, the system accesses the resource cache (orthe directory server) to determine what authentication challenge methodis to be used for the given resource. The system then accesses theauthentication scheme cache (or the directory server) in step 2922 todetermine whether the authentication scheme associated with therequested resource has been previously cached. If the authenticationscheme is found, then the system determines the specific type ofchallenge method in step 2926. If the challenge scheme was not found instep 2922, the system loads the authentication rule associated with therequested resource from Directory Server 36 in step 2924, and thenproceeds to step 2926.

[0481] In step 2926, the system discerns whether the authenticationchallenge scheme retrieved calls for basic, form, certificate, or noauthentication. If the challenge scheme indicates basic authentication,then the method proceeds to step 2928 and performs basic authentication.If the challenge scheme indicates form authentication, then the methodproceeds to step 2930 and performs form authentication. If the challengescheme indicates certificate authentication, then the method proceeds tostep 2932 and performs certificate authentication. If the challengescheme indicates that no authentication is required (step 2934), thenthe user is not challenged, authentication is not performed.

[0482]FIG. 71 provides a block diagram of an authentication cookie 3150passed by Web Gate 28 to browser 12 in step 2580 of FIG. 65. Cookie 3150is encrypted with a symmetric cipher so that cookies from all instancesof Web Gate 28 in a given deployment of the present invention may beencrypted using the same key. This key (called a shared secret) isstored on Directory Server 36 and distributed to each of the Web Gates28 by Access Server 34. The shared secret can change as often as desiredby an administrator. In one embodiment of the present invention, cookie3150 is encrypted using RC4 encryption with a 2048 bit key. In oneembodiment, previously valid keys are grandfathered such that both thecurrent key and the immediately prior key will both work to de-cryptencrypted cookie 3150. The present invention features a one-button keyre-generation function. This function is easily scriptable.

[0483] In one embodiment, the information stored by cookie 3150includes: (1) the authentication level 3152 of the authentication schemeused to create the cookie, (2) the user ID 3154 of the authenticateduser, (3) the IP address 3156 of the authenticated user, and (4) sessionstart time 3158 identifying the time at which cookie 3150 was created.If the time elapsed since the session start time 3158 exceeds a maximumsession time, the cookie will become invalid. Idle start time 3160 isalso stored, which identifies the time when the previous HTTP requestfor a protected resource was made in which cookie 3150 was passed. Ifthe time elapsed since the idle start time 3160 exceeds a maximum idletime, the cookie will become invalid. Both of these time limits forceusers to re-authenticate if they have left a session unattended forlonger than the maximum session or idle times. In one embodiment, userID 3154 stores the distinguished name for the authenticated user.

[0484] Cookie 3150 also stores a secured hash 3162 of information 3152,3154, 3156, 3158, and 3160. In one embodiment of the present invention,secured hash 3162 is created using an MD5 hashing algorithm. MostInternet browsers cache a user's supplied authentication informationduring basic and certificate authentication challenge methods, and thentransparently re-send the information upon receiving an authenticationchallenge from a Web Server. In one embodiment, an administrator canenable a form authentication challenge method requiring end users tore-authenticate upon expiration of the maximum session or maximum idletime limits.

[0485]FIG. 72 provides a flow chart describing a method for attemptingto authorize a user. In step 3194, Access Server 34 determines whetherone or more authorization rules associated with the requested resourceare found in an authorization rule cache. If one or more rules arefound, Access Server 34 proceeds to step 3196. Otherwise, Access Server34 retrieves any authorization rules associated with the requestedresource from Directory Server 36 in step 3198. In one embodiment,authorization success and failure actions are retrieved with theauthorization rules. After retrieving the authorization rules, AccessServer 34 proceeds to step 3196 and reads the first authorization ruleassociated with the requested resource from the authorization rulecache. Access Server 34 applies the authorization rule in step 3200.

[0486] If the authorization rule is satisfied in step 3202, AccessServer 34 determines whether the identity profile attributes for theuser are found in a user profile cache (step 3204). If so, Access Server34 proceeds to step 3208. If not, Access Server 34 retrieves theattributes of the current user (step 3207), and communicates theauthorization success actions and attributes to Web Gate 28 (step 3208).

[0487] If the authorization rule is not satisfied (step 3202), thenAccess Server 34 determines whether more authorization rules remain tobe evaluated (step 3209). If more rules remain, the next rule is read(step 3196) and evaluated (step 3200). If no more rules remain, AccessServer 34 determines whether the attributes for the user is found in theuser profile cache (step 3210). If so, Access Server 34 proceeds to step3212. If not, Access Server 34 retrieves the attributes of the currentuser (step 3211), and communicates the authorization success actions andattributes to Web Gate 28 (step 3212).

[0488]FIG. 73 provides a flow chart describing a method for loading anauthorization rule from Directory Server 36. In step 3280, Access Server34 loads the default authorization rule for the mapped policy domainfrom Directory Server 36 into the authorization rule cache. AccessServer 34 then selects a first rule (step 3282) and determines whetherthe selected rule is a second level (specific) rule of a policyassociated with the requested resource (step 3284). If yes, then AccessServer 34 proceeds to step 3292. Otherwise, Access Server 34 determineswhether all rules in the array have been evaluated (step 3286). If not,then Access Server 34 selects the next rule (step 3288) and returns tostep 3284. Once all rules in the array have been considered (step 3286),Access Server 34 proceeds to step 3294. If a second level authorizationrule (a rule defined in a policy) was found for the requested resourcein step 3284, then Access Server 34 caches the second levelauthorization rule in the authorization rule cache (step 3292). If asecond level policy authorization rule was not found, then the defaultauthorization rule previously loaded in step 3280 remains the onlyrelevant rule in the authorization rule cache.

[0489]FIG. 74 provides a flow chart describing the method of applying anauthorization rule (step 3200 of FIG. 72). In one embodiment,authorization can be performed using POST data. In another embodiment,POST data is not used for authorization. If POST data is to be used forauthorization, then the method of FIG. 74 begins with optional step3320. Otherwise, the method begins at step 3324. In optional step 3320,if the resource request employs a POST request method, then AccessServer 34 proceeds to optional step 3322 where it applies theauthorization rule to the POST data.

[0490] If the resource request does not employ a POST request method (orif POST data is not enabled to be used for authorization), then AccessServer 34 proceeds to step 3324. If specific users are defined (bydistinguished name) in the authorization rule, Access Server 34evaluates whether the distinguished name of the authenticated usermatches the distinguished name(s) called for by the authorization rule(step 3326). If specific groups are defined in the authorization rule(step 3328), Access Server 34 evaluates whether the authenticated useris a member of the groups identified in the authorization rule (step3330). If specific roles are defined in the authorization rule (step3332), then Access Server 34 evaluates whether the role of theauthenticated user matches the role called for by the authorization rule(step 3334). If specific LDAP rules are defined in the authorizationrule (step 3340), Access Server 34 evaluates whether the attributes ofthe authenticated user (and/or other data) satisfy the LDAP rule of theauthorization rule (step 3342). In one embodiment, the result of theLDAP rule evaluation in step 3342 is cached. If specific IP addressesare defined in the authorization rule (step 3344), Access Server 34evaluates whether the IP address of the authenticated user matches theIP address called for by the authorization rule (step 3346). If asuccessful match is found at any point (steps 3327, 3331, 3335, 3343,and 3347), the authorization is successful (step 3350). If no matchesare found, authorization is unsuccessful (step 3352). In someembodiments, authorization is only successful if multiple matches arefound. For example, a user must have the appropriate rule, be a memberof the appropriate group and have an appropriate IP address.

[0491] More details of various processes for authenticating andauthorizing, including using an application programinterface, can befound in U.S. patent application Ser. No. 09/814,091, “Access SystemInterface,” filed on Mar. 21, 2001, Charles W. Knouse and Minoo Gupta(“'091 Application”), which in its entirety is incorporated herein byreference. Specifically, FIGS. 14-56 of the '091 Application describethe details of one set of implementations for authenticating andauthorizing. FIGS. 58-62 of the '091 Application describe a set ofembodiments that use an application program interface for accessing thesystem. The present invention can make use of the authentication and/orauthorization technology described in the '091 Patent or various othermethods of authentication and/or authorization.

[0492] The foregoing detailed description of the invention has beenpresented for purposes of illustration and description. It is notintended to be exhaustive or to limit the invention to the precise formdisclosed. Many modifications and variations are possible in light ofthe above teaching. The described embodiments were chosen in order tobest explain the principles of the invention and its practicalapplication to thereby enable others skilled in the art to best utilizethe invention in various embodiments and with various modifications asare suited to the particular use contemplated. It is intended that thescope of the invention be defined by the claims appended hereto.

I claim:
 1. A method for caching data associated with entries in a data store accessed in response to a request assigned to a thread of execution, said method comprising the steps of: (a) interpreting a first command arising from said request to call for access to a data store entry in said data store; and (b) accessing a first entry in a cache object in response to said first command, wherein said first entry corresponds to said data store entry, wherein said cache object is associated with said thread of execution, and wherein said cache object is only accessed in response to commands arising from requests assigned to said thread of execution.
 2. The method of claim 1, further including the step of: (c) destroying said cache object in response to said request being completed.
 3. The method of claim 1, wherein said first command calls for writing a value to said data store entry, wherein said step (b) includes the steps of: (1) writing said value to said first entry in said cache object; and (2) writing said value to said data store entry.
 4. The method of claim 3, wherein a second command arising from said request calls for a query from said data store entry, wherein said method further includes the step of: (d) retrieving said value from said first entry in said cache object.
 5. The method of claim 1, wherein said thread of execution contains a thread local storage with a pointer to said cache object.
 6. The method of claim 5, wherein said thread of execution exists in an Identity Server in communication with said data store.
 7. The method of claim 6, wherein said data store is in communication with an Access Server.
 8. The method of claim 1, further including the steps of: (e) determining that said cache object does not contain an entry corresponding to said data store entry; and (f) creating said first entry in said cache object.
 9. The method of claim 1, wherein said cache object cannot be accessed in response to commands arising from requests other than said request assigned to said thread of execution.
 10. The method of claim 1, wherein said cache is not updated in response to entries in said data store being changed in response to requests other than said request assigned to said thread of execution.
 11. One or more processor readable storage devices having processor readable code embodied on said processor readable storage devices, said processor readable code for programming one or more processors to perform a method for caching data associated with entries in a data store accessed in response to a request assigned to a thread of execution, said method comprising the steps of: (a) interpreting a first command arising from said request to call for access to a data store entry in said data store; and (b) accessing a first entry in a cache object in response to said first command, wherein said first entry corresponds to said data store entry, wherein said cache object is associated with said thread of execution, and wherein said cache object is only accessed in response to commands arising from requests assigned to said thread of execution.
 12. One or more processor readable storage devices according to claim 11, wherein said method further includes the step of: (c) destroying said cache object in response to said request being completed.
 13. One or more processor readable storage devices according to claim 11, wherein said first command calls for writing a value to said data store entry, wherein said step (b) includes the steps of: (1) writing said value to said first entry in said cache object; and (2) writing said value to said data store entry.
 14. One or more processor readable storage devices according to claim 13, wherein a second command arising from said request calls for a query from said first data store entry, wherein said method further includes the step of: (d) retrieving said value from said first entry in said cache object.
 15. One or more processor readable storage devices according to claim 11, wherein said thread of execution contains a thread local storage with a pointer to said cache object.
 16. One or more processor readable storage devices according to claim 15, wherein said thread of execution exists in an Identity Server in communication with said data store, and wherein said data store is in communication with an Access Server.
 17. One or more processor readable storage devices according to claim 11, wherein said method further includes the steps of: (e) determining that said cache object does not contain an entry corresponding to said data store entry; and (f) creating said first entry in said cache object.
 18. One or more processor readable storage devices according to claim 11, wherein said cache object cannot be accessed in response to commands arising from requests other than said request assigned to said thread of execution.
 19. One or more processor readable storage devices according to claim 11, wherein said cache is not updated in response to entries in said data store being changed in response to requests other than said request assigned to said thread of execution.
 20. A system having a server in communication with a data store, said system comprising: one or more communication interfaces; one or more storage devices; a thread local storage in said server, wherein said thread local storage is associated with a thread of execution on said server; a cache object associated with said thread local storage; and one or more processors in communication with said one or more storage devices and said one or more communication interfaces, wherein said one or more processors perform a method for caching data associated with entries in said data store accessed in response to a request assigned to said thread of execution, said method comprising the steps of: (a) interpreting a first command arising from said request to call for access to a data store entry in said data store; and (b) accessing a first entry in a cache object in response to said first command, wherein said first entry corresponds to said data store entry, wherein said cache object is associated with said thread of execution, and wherein said cache object is only accessed in response to commands arising from requests assigned to said thread of execution.
 21. The system of claim 20, further including the step of: (c) destroying said cache object in response to said request being completed.
 22. The system of claim 20, wherein said first command calls for writing a value to said data store entry, wherein said step (b) includes the steps of: (1) writing said value to said first entry in said cache object; and (2) writing said value to said data store entry.
 23. The system of claim 22, wherein a second command arising from said request calls for a query from said first data store entry, wherein said method further includes the step of: (d) retrieving said value from said first entry in said cache object.
 24. The system of claim 20, wherein said thread of execution contains a thread local storage with a pointer to said cache object.
 25. The system of claim 20, wherein said method further includes the steps of: (e) determining that said cache object does not contain an entry corresponding to said first data store entry; and (f) creating said first entry in said cache object.
 26. The system of claim 20, further including: a Web Server in communication with said server computer, wherein said server computer is an Identity Server; and an Access System in communication with said Identity Server, wherein said Access System includes a Web Server in communication with an Access Server, wherein said Access Server is in communication with said data store.
 27. The system of claim 20, wherein said cache object cannot be accessed in response to commands arising from requests other than said request assigned to said thread of execution.
 28. The system of claim 20, wherein said cache is not updated in response to entries in said data store being changed in response to requests other than said request assigned to said thread of execution.
 29. A method for caching data associated with entries in a data store accessed in response to a request assigned to a thread of execution, said method comprising the steps of: (a) interpreting a first command arising from said request to call for access to a data store entry in said data store; (b) accessing a first entry in a cache object in response to said first command, wherein said first entry corresponds to said data store entry, wherein said cache object is associated with said thread of execution, wherein said thread of execution contains a thread local storage with a pointer to said cache object, wherein said cache object is only accessed in response to commands arising from said request assigned to said thread of execution, wherein said first command calls for writing a value to said data store entry, and wherein said step (b) includes the steps of: (1) writing said value to said first entry in said cache object, and (2) writing said value to said data store entry; (c) retrieving said value from said first entry in said cache object in response to a second command arising from said request, wherein said second command calls for a query from said data store entry; and (d) destroying said cache object in response to said request being completed.
 30. The method of claim 29, wherein said thread of execution exists in an Identity Server in communication with said data store, and said data store is in communication with an Access Server.
 31. One or more processor readable storage devices having processor readable code embodied on said processor readable storage devices, said processor readable code for programming one or more processors to perform a method for caching data associated with entries in a data store accessed in response to a request assigned to a first thread of execution, said method comprising the steps of: (a) interpreting a first command arising from said request to call for access to a data store entry in said data store; (b) accessing a first entry in a cache object in response to said first command, wherein said first entry corresponds to said data store entry, wherein said cache object is associated with said thread of execution, wherein said thread of execution contains a thread local storage with a pointer to said cache object, wherein said cache object is only accessed in response to commands arising from requests assigned to said thread of execution, wherein said first command calls for writing a value to said data store entry, and wherein said step (b) includes the steps of: (1) writing said value to said first entry in said cache object; and (2) writing said value to said data store entry; (c) retrieving said value from said first entry in said cache object in response to a second command arising from said request, wherein said second command calls for a query from said data store entry; and (d) destroying said cache object in response to said request being completed.
 32. One or more processor readable storage devices according to claim 31, wherein said thread of execution exists in an Identity Server in communication with said data store, and said data store is in communication with an Access Server.
 33. A system having a server in communication with a data store, said system comprising: one or more communication interfaces; one or more storage devices; a thread local storage in said server, wherein said thread local storage is associated with a thread of execution on said server; a cache object associated with said thread local storage; and one or more processors in communication with said one or more storage devices and said one or more communication interfaces, wherein said one or more processors perform a method for caching data associated with entries in said data store accessed in response to a request assigned to said thread of execution, said method comprising the steps of: (a) interpreting a first command arising from said request to call for access to a data store entry in said data store; (b) accessing a first entry in a cache object in response to said first command, wherein said first entry corresponds to said data store entry, wherein said cache object is associated with said thread of execution, wherein said thread local storage contains a pointer to said cache object, wherein said cache object is only accessed in response to commands arising from said request assigned to said thread of execution, wherein said first command calls for writing a value to said data store entry, and wherein said step (b) includes the steps of: (1) writing said value to said first entry in said cache object, and (2) writing said value to said data store entry; (c) retrieving said value from said first entry in said cache object in response to a second command arising from said request, wherein said second command calls for a query from said data store entry; and (d) destroying said cache object in response to said request being completed.
 34. The system of claim 33, further including: a Web Server in communication with said server computer, wherein said server computer is an Identity Server; and an Access System in communication with said Identity Server, wherein said Access System includes a Web Server in communication with an Access Server, wherein said Access Server is in communication with said data store. 